Menu
▾
▴
phpwiki-talk
|
From: Manuel V. <man...@st...> - 2004-11-25 16:03:30
|
Hi all, In order to be able to run multiple instances of PhpWiki based on the same sources and the same DB, I want to modify WikiDB and corresponding backends (at beginning PearDB) to add an unique id for each PhpWiki instances. My idea is: - to add a field in the Db. - modify all access to Db in backend/PearDb to include the good id. Do you think that's it would be suffisant or not? Regards, Manuel |
|
From: Reini U. <ru...@x-...> - 2004-11-25 17:08:53
|
Manuel VACELET schrieb: > In order to be able to run multiple instances of PhpWiki based on the > same sources and the same DB, I want to modify WikiDB and corresponding > backends (at beginning PearDB) to add an unique id for each PhpWiki > instances. why? don't do that! just define a different DATABASE_PREFIX for each wiki and generate the tables with these prefixes. > My idea is: > - to add a field in the Db. > - modify all access to Db in backend/PearDb to include the good id. > > Do you think that's it would be suffisant or not? |
|
From: Manuel V. <man...@st...> - 2004-11-26 08:42:24
|
Reini Urban wrote: > Manuel VACELET schrieb: > >> In order to be able to run multiple instances of PhpWiki based on the >> same sources and the same DB, I want to modify WikiDB and >> corresponding backends (at beginning PearDB) to add an unique id for >> each PhpWiki instances. > > > why? don't do that! > just define a different DATABASE_PREFIX for each wiki and generate the > tables with these prefixes. I want to offer phpwiki servicies to mutiple groups (I'm looking around gforge wiki plugin). For security reason I have to separate content of each instances of PhpWiki. I can have thousand instances of phpwiki so it imply ten thousand mysql tables. I already (successfully) tested database prefix but I think next phpwiki updates (with db schema upgrades) will be a little bit complicated. But it's just "feeling" about possible issues, I don't really have examples of "Why I think that it could be a problem?" Regards, Manuel |
|
From: Reini U. <ru...@x-...> - 2004-11-26 09:22:57
|
Manuel VACELET schrieb:
> Reini Urban wrote:
>> Manuel VACELET schrieb:
>>> In order to be able to run multiple instances of PhpWiki based on the
>>> same sources and the same DB, I want to modify WikiDB and
>>> corresponding backends (at beginning PearDB) to add an unique id for
>>> each PhpWiki instances.
>>
>> why? don't do that!
>> just define a different DATABASE_PREFIX for each wiki and generate the
>> tables with these prefixes.
>
> I want to offer phpwiki servicies to mutiple groups (I'm looking around
> gforge wiki plugin). For security reason I have to separate content of
> each instances of PhpWiki. I can have thousand instances of phpwiki so
> it imply ten thousand mysql tables.
>
> I already (successfully) tested database prefix but I think next phpwiki
> updates (with db schema upgrades) will be a little bit complicated.
So please use different databases for this task. Just a different DSN.
You can do that automatically by creating the DSN automatically
e.g. by prefixing the database with the gforge project name.
("myproject_phpwiki")
Or even use the gforge database "myproject" and just add some general
"phpwiki_" prefix.
Either prefixes or databases.
I see no technical reason for a WikiDB db_id.
In gforge there's no need for a custom starter script for each project,
you can do that automatically, by creating these wiki settings from your
app. Just define the general settings in the central config/config.ini
and define the custom overrides in the script behind the wiki link.
BTW: In CVS there's no nameclash with $Theme anymore, but 1.3.10 is not
usable with gforge.
> But it's just "feeling" about possible issues, I don't really have
> examples of "Why I think that it could be a problem?"
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Dan F. <dfr...@cs...> - 2005-01-07 14:48:27
|
Reini Urban wrote:
> Manuel VACELET schrieb:
>
>> Reini Urban wrote:
>>
>>> Manuel VACELET schrieb:
>>>
>>>> In order to be able to run multiple instances of PhpWiki based on
>>>> the same sources and the same DB, I want to modify WikiDB and
>>>> corresponding backends (at beginning PearDB) to add an unique id
>>>> for each PhpWiki instances.
>>>
>>>
>>> why? don't do that!
>>> just define a different DATABASE_PREFIX for each wiki and generate
>>> the tables with these prefixes.
>>
>>
>> I want to offer phpwiki servicies to mutiple groups (I'm looking
>> around gforge wiki plugin). For security reason I have to separate
>> content of each instances of PhpWiki. I can have thousand instances
>> of phpwiki so it imply ten thousand mysql tables.
>>
>> I already (successfully) tested database prefix but I think next
>> phpwiki updates (with db schema upgrades) will be a little bit
>> complicated.
>
>
> So please use different databases for this task. Just a different DSN.
> You can do that automatically by creating the DSN automatically
> e.g. by prefixing the database with the gforge project name.
> ("myproject_phpwiki")
> Or even use the gforge database "myproject" and just add some general
> "phpwiki_" prefix.
>
> Either prefixes or databases.
> I see no technical reason for a WikiDB db_id.
I can certainly imagine a reason to want multiple wiki instances in a
single database. It's for ease of management.
Suppose there is something that breaks upon upgrade for some DBs. If you
have 10,000 DBs, then you have to nurse each one. Or suppose that you
wish to change the parameters of the DB for size or performance. One can
either apply that once, or have to somehow apply it 10,000 times. There
are definite advantages to grouping wikis into a single DB.
On the other hand, that doesn't mean it's easy to change Phpwiki to do that.
Dan
|
|
From: Manuel V. <man...@st...> - 2005-01-07 14:56:57
|
Dan Frankowski wrote:
> Reini Urban wrote:
>
>> Manuel VACELET schrieb:
>>
>>> Reini Urban wrote:
>>>
>>>> Manuel VACELET schrieb:
>>>>
>>>>> In order to be able to run multiple instances of PhpWiki based on
>>>>> the same sources and the same DB, I want to modify WikiDB and
>>>>> corresponding backends (at beginning PearDB) to add an unique id
>>>>> for each PhpWiki instances.
>>>>
>>>>
>>>>
>>>> why? don't do that!
>>>> just define a different DATABASE_PREFIX for each wiki and generate
>>>> the tables with these prefixes.
>>>
>>>
>>>
>>> I want to offer phpwiki servicies to mutiple groups (I'm looking
>>> around gforge wiki plugin). For security reason I have to separate
>>> content of each instances of PhpWiki. I can have thousand instances
>>> of phpwiki so it imply ten thousand mysql tables.
>>>
>>> I already (successfully) tested database prefix but I think next
>>> phpwiki updates (with db schema upgrades) will be a little bit
>>> complicated.
>>
>>
>>
>> So please use different databases for this task. Just a different DSN.
>> You can do that automatically by creating the DSN automatically
>> e.g. by prefixing the database with the gforge project name.
>> ("myproject_phpwiki")
>> Or even use the gforge database "myproject" and just add some general
>> "phpwiki_" prefix.
>>
>> Either prefixes or databases.
>> I see no technical reason for a WikiDB db_id.
>
> I can certainly imagine a reason to want multiple wiki instances in a
> single database. It's for ease of management.
>
> Suppose there is something that breaks upon upgrade for some DBs. If you
> have 10,000 DBs, then you have to nurse each one. Or suppose that you
> wish to change the parameters of the DB for size or performance. One can
> either apply that once, or have to somehow apply it 10,000 times. There
> are definite advantages to grouping wikis into a single DB.
>
> On the other hand, that doesn't mean it's easy to change Phpwiki to do
> that.
Even if Reini said to avoid this idea from my mind ... I did it :)
On phpwiki 1.3.10 I made a hack to add a wiki identifier in the DB and
in the mysql back end.
My hacked phpwiki runs since the beginning of december with around 10
wiki on the same set of tables and there is -I hope- no conflicts.
I could give you a patch if you are under interest.
Best regards,
Manuel
--
# VACELET Manuel manuel.vacelet-abecedaire(at)st(dot)com #
# Tel: 042 6089 +33 (0)476 92 6089 #
# STMicroelectronics #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE #
|
|
From: Dan F. <dfr...@cs...> - 2005-01-07 15:14:39
|
Manuel VACELET wrote:
> Dan Frankowski wrote:
>
>> Reini Urban wrote:
>>
>>> Manuel VACELET schrieb:
>>>
>>>> Reini Urban wrote:
>>>>
>>>>> Manuel VACELET schrieb:
>>>>>
>>>>>> In order to be able to run multiple instances of PhpWiki based on
>>>>>> the same sources and the same DB, I want to modify WikiDB and
>>>>>> corresponding backends (at beginning PearDB) to add an unique id
>>>>>> for each PhpWiki instances.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> why? don't do that!
>>>>> just define a different DATABASE_PREFIX for each wiki and generate
>>>>> the tables with these prefixes.
>>>>
>>>>
>>>>
>>>>
>>>> I want to offer phpwiki servicies to mutiple groups (I'm looking
>>>> around gforge wiki plugin). For security reason I have to separate
>>>> content of each instances of PhpWiki. I can have thousand instances
>>>> of phpwiki so it imply ten thousand mysql tables.
>>>>
>>>> I already (successfully) tested database prefix but I think next
>>>> phpwiki updates (with db schema upgrades) will be a little bit
>>>> complicated.
>>>
>>>
>>>
>>>
>>> So please use different databases for this task. Just a different DSN.
>>> You can do that automatically by creating the DSN automatically
>>> e.g. by prefixing the database with the gforge project name.
>>> ("myproject_phpwiki")
>>> Or even use the gforge database "myproject" and just add some
>>> general "phpwiki_" prefix.
>>>
>>> Either prefixes or databases.
>>> I see no technical reason for a WikiDB db_id.
>>
>>
>> I can certainly imagine a reason to want multiple wiki instances in a
>> single database. It's for ease of management.
>>
>> Suppose there is something that breaks upon upgrade for some DBs. If
>> you have 10,000 DBs, then you have to nurse each one. Or suppose that
>> you wish to change the parameters of the DB for size or performance.
>> One can either apply that once, or have to somehow apply it 10,000
>> times. There are definite advantages to grouping wikis into a single DB.
>>
>> On the other hand, that doesn't mean it's easy to change Phpwiki to
>> do that.
>
>
> Even if Reini said to avoid this idea from my mind ... I did it :)
>
> On phpwiki 1.3.10 I made a hack to add a wiki identifier in the DB and
> in the mysql back end.
>
> My hacked phpwiki runs since the beginning of december with around 10
> wiki on the same set of tables and there is -I hope- no conflicts.
>
> I could give you a patch if you are under interest.
That's cool. You should submit a patch to Phpwiki, just in case Reini
changes his mind. :-) Here is SourceForge's patches tracker:
http://sourceforge.net/tracker/?atid=306121&group_id=6121&func=browse
Dan
|
|
From: Manuel V. <man...@st...> - 2005-01-07 15:44:56
|
Dan Frankowski wrote: > That's cool. You should submit a patch to Phpwiki, just in case Reini > changes his mind. :-) Here is SourceForge's patches tracker: Patch available here https://sourceforge.net/tracker/index.php?func=detail&aid=1097938&group_id=6121&atid=306121 Hope it could help. Manuel -- # VACELET Manuel manuel.vacelet-abecedaire(at)st(dot)com # # Tel: 042 6089 +33 (0)476 92 6089 # # STMicroelectronics # # 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE # |
|
From: Reini U. <ru...@x-...> - 2005-01-07 16:17:00
|
Manuel VACELET schrieb: > Dan Frankowski wrote: >> That's cool. You should submit a patch to Phpwiki, just in case Reini >> changes his mind. :-) Here is SourceForge's patches tracker: > > Patch available here > https://sourceforge.net/tracker/index.php?func=detail&aid=1097938&group_id=6121&atid=306121 I'll have a look after 1.3.11 but I still see no technical reason, why this should be better than tablename prefixes. Merging all the seperate table sets into one big mess... >I can certainly imagine a reason to want multiple wiki instances in a >single database. It's for ease of management. >Suppose there is something that breaks upon upgrade for some DBs. If >you have 10,000 DBs, then you have to nurse each one. Or suppose that >you wish to change the parameters of the DB for size or performance. >One can either apply that once, or have to somehow apply it 10,000 >times. There are definite advantages to grouping wikis into a single >DB. Other than helping administrative SQL tasks outside the wiki maybe. Schema upgrades are done now via action=upgrade. But a simple mysql script is also easy, looping over all existing prefixes. Should I provide such a script for wikifarm schema upgrades? But for gforge integration it is really not needed. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Manuel V. <man...@st...> - 2005-01-07 16:31:16
|
Reini Urban wrote: > I'll have a look after 1.3.11 but I still see no technical reason, why > this should be better than tablename prefixes. Merging all the seperate > table sets into one big mess... I agree, it's not technical reasons. I just "fell" it not very elegant (tables multiplications). > Other than helping administrative SQL tasks outside the wiki maybe. > Schema upgrades are done now via action=upgrade. > But a simple mysql script is also easy, looping over all existing > prefixes. Should I provide such a script for wikifarm schema upgrades? I think that wikifarm users are able to do their own upgrades. > But for gforge integration it is really not needed. I discuss very long time with Christian Bayle from gforge team and we have the same felling: "multiplication of tables is bad" but without rational facts to justify our feeling. Current way of phpwiki integration under gforge is to have only one wiki and each project create pages into this big wiki. My way is to provide one independent wiki for each project. Current state seems to work (around 1 month of tests without any problems) but I prefer waiting for phpwiki 1.3.11 release before release the plugin. Regards, Manuel -- # VACELET Manuel manuel.vacelet-abecedaire(at)st(dot)com # # Tel: 042 6089 +33 (0)476 92 6089 # # STMicroelectronics # # 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE # |
|
From: Reini U. <ru...@x-...> - 2005-01-07 19:30:46
|
Manuel VACELET schrieb:
> Reini Urban wrote:
>
>> I'll have a look after 1.3.11 but I still see no technical reason, why
>> this should be better than tablename prefixes. Merging all the
>> seperate table sets into one big mess...
>
> I agree, it's not technical reasons.
> I just "fell" it not very elegant (tables multiplications).
>
>> Other than helping administrative SQL tasks outside the wiki maybe.
>> Schema upgrades are done now via action=upgrade.
>> But a simple mysql script is also easy, looping over all existing
>> prefixes. Should I provide such a script for wikifarm schema upgrades?
>
> I think that wikifarm users are able to do their own upgrades.
>
>> But for gforge integration it is really not needed.
>
> I discuss very long time with Christian Bayle from gforge team and we
> have the same felling: "multiplication of tables is bad" but without
> rational facts to justify our feeling.
>
> Current way of phpwiki integration under gforge is to have only one wiki
> and each project create pages into this big wiki. My way is to provide
> one independent wiki for each project.
Well, my way for gforge intergration would use a project-specific
DATABASE_PREFIX, set by the plugin.
DB: phpwiki
tables: project1_page, project1_version, project1_recent, ...
project2_page, project2_version, project2_recent, ...
needs project_name
you can even use different wiki engines per project.
Your id scheme is simplier on the database level.
DB: phpwiki
tables: page (with group_id), version, recent, ...
needs group_id
just one engine and one database schema.
Pro: * You only have to do structure updates once,
and use a new primary index: pagename+id
* easier to upgrade to a new phpwiki schema and version.
Cons: * Seperation into different wiki's is hard.
* you cannot do project specific phpwiki updates.
* will not by supported by phpwiki OOTB.
So gforge sites must patch the WikiDB backends.
I cannot accept your page.group_id patch into phpwiki.
It is way to abusive.
> Current state seems to work (around 1 month of tests without any
> problems) but I prefer waiting for phpwiki 1.3.11 release before release
> the plugin.
The sql schema will not change anymore for sure.
Maybe some minor issues with exotic backends have to fixed.
Major goals are only the request enhancements in main and Request
(GET => POST for ModeratedPage, maybe edit), check remaining request
problems (session, edit + redirect)
wikiparser fixes for php5 (or output?),
some remaining theme updates
configurator for lists
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Manuel V. <man...@st...> - 2005-01-10 13:17:36
|
Reini Urban wrote: > Well, my way for gforge intergration would use a project-specific > DATABASE_PREFIX, set by the plugin. > > DB: phpwiki > tables: project1_page, project1_version, project1_recent, ... > project2_page, project2_version, project2_recent, ... > needs project_name > you can even use different wiki engines per project. My first version of the plugin was based on this schema. But It wasn't accepted by gforge team leader. > Your id scheme is simplier on the database level. > DB: phpwiki > tables: page (with group_id), version, recent, ... > needs group_id > just one engine and one database schema. > > Pro: * You only have to do structure updates once, > and use a new primary index: pagename+id > * easier to upgrade to a new phpwiki schema and version. > Cons: * Seperation into different wiki's is hard. > * you cannot do project specific phpwiki updates. > * will not by supported by phpwiki OOTB. > So gforge sites must patch the WikiDB backends. > > I cannot accept your page.group_id patch into phpwiki. > It is way to abusive. There are no problems for me, I can maintain my patch myself: I made it, I assume it ;) > The sql schema will not change anymore for sure. > Maybe some minor issues with exotic backends have to fixed. Great, no maintainance operations! > Major goals are only the request enhancements in main and Request > (GET => POST for ModeratedPage, maybe edit), check remaining request > problems (session, edit + redirect) > wikiparser fixes for php5 (or output?), > some remaining theme updates > configurator for lists Well, we are close to PhpWiki 1.3.11 that's a good news. -- # VACELET Manuel manuel.vacelet-abecedaire(at)st(dot)com # # Tel: 042 6089 +33 (0)476 92 6089 # # STMicroelectronics # # 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE # |
|
From: Christian B. <chr...@fr...> - 2005-01-14 23:03:13
|
Le vendredi 07 janvier 2005 =E0 20:30 +0100, Reini Urban a =E9crit : > Manuel VACELET schrieb: > > Reini Urban wrote: > >=20 > >> I'll have a look after 1.3.11 but I still see no technical reason, why= =20 > >> this should be better than tablename prefixes. Merging all the=20 > >> seperate table sets into one big mess... > >=20 > > I agree, it's not technical reasons. > > I just "fell" it not very elegant (tables multiplications). > >=20 I see finally some important technical reasons after some discussion:=20 -Upgrading 4000 set of tables can be some kind of tricky. The main question is to have isolated group spaces in the wiki, that is not as far as i understand in phpwiki philosophy. -Having group of pages associated with a project, where you can make some kind of access control possibly at page level: public or private. -Each project gathering a group of users. How would you implement this, if you had to do it, is the way followed by Manuel the best one, according to the fact we don't want database or table multiplication Thanks for your help Cheers Christian.=20 > >=20 > > Current way of phpwiki integration under gforge is to have only one wik= i=20 > > and each project create pages into this big wiki. My way is to provide=20 > > one independent wiki for each project. >=20 > Well, my way for gforge intergration would use a project-specific=20 > DATABASE_PREFIX, set by the plugin. >=20 > DB: phpwiki > tables: project1_page, project1_version, project1_recent, ... > project2_page, project2_version, project2_recent, ... > needs project_name > you can even use different wiki engines per project. >=20 > Your id scheme is simplier on the database level. > DB: phpwiki > tables: page (with group_id), version, recent, ... > needs group_id > just one engine and one database schema. >=20 > Pro: * You only have to do structure updates once, > and use a new primary index: pagename+id > * easier to upgrade to a new phpwiki schema and version. > Cons: * Seperation into different wiki's is hard. > * you cannot do project specific phpwiki updates. > * will not by supported by phpwiki OOTB. > So gforge sites must patch the WikiDB backends. >=20 > I cannot accept your page.group_id patch into phpwiki. > It is way to abusive. >=20 > > Current state seems to work (around 1 month of tests without any=20 > > problems) but I prefer waiting for phpwiki 1.3.11 release before releas= e=20 > > the plugin. >=20 > The sql schema will not change anymore for sure. > Maybe some minor issues with exotic backends have to fixed. >=20 > Major goals are only the request enhancements in main and Request > (GET =3D> POST for ModeratedPage, maybe edit), check remaining request=20 > problems (session, edit + redirect) > wikiparser fixes for php5 (or output?), > some remaining theme updates > configurator for lists |
|
From: Reini U. <ru...@x-...> - 2005-01-15 00:11:06
|
Christian BAYLE schrieb:
> Le vendredi 07 janvier 2005 à 20:30 +0100, Reini Urban a écrit :
>>Manuel VACELET schrieb:
>>>Reini Urban wrote:
>>>
>>>>I'll have a look after 1.3.11 but I still see no technical reason, why
>>>>this should be better than tablename prefixes. Merging all the
>>>>seperate table sets into one big mess...
>>>
>>>I agree, it's not technical reasons.
>>>I just "fell" it not very elegant (tables multiplications).
>
> I see finally some important technical reasons after some discussion:
> -Upgrading 4000 set of tables can be some kind of tricky.
A simple perl or php script?
> The main question is to have isolated group spaces in the wiki, that is
> not as far as i understand in phpwiki philosophy.
> -Having group of pages associated with a project, where you can make
> some kind of access control possibly at page level: public or private.
> -Each project gathering a group of users.
>
> How would you implement this, if you had to do it, is the way followed
> by Manuel the best one, according to the fact we don't want database or
> table multiplication
Ok. I see your point now.
auth and perm control, across groups:
access control by group level (public or private) would be easy by
defining this constant in the starter script, dependent on the group_id.
(some pgsql query from the gforge cfg).
if (
user auth (userid+passwd) is already easy via external db.
also via session:
// If the user is logged in, let the Wiki know
if (session_loggedin()) {
// let php do it's session stuff too!
session_start();
$_SESSION['user_id'] = user_getname(); // phpwiki will pick it up.
}
or via the undocumented Session auth:
define('AUTH_SESS_USER', 'user_id');
define('AUTH_SESS_LEVEL', 2);
$USER_AUTH_ORDER = "Session : PersonalPage";
$USER_AUTH_POLICY = "stacked";
db upgrade:
table schema multiplication might be problematic, but could be done by
some simple helper script. It's technically not the best solution, but
at least the tables are fully independent. ISP's usually prefer
independence over technical superiority.
A seperate database per group is technically and in administrative terms
the worst solution.
Your required wikidb patch for the queries (WHERE group_id=) is quite
simple. That would fit best to the gforge philosophy.
>>>Current way of phpwiki integration under gforge is to have only one wiki
>>>and each project create pages into this big wiki. My way is to provide
>>>one independent wiki for each project.
>>
>>Well, my way for gforge intergration would use a project-specific
>>DATABASE_PREFIX, set by the plugin.
>>
>>DB: phpwiki
>> tables: project1_page, project1_version, project1_recent, ...
>> project2_page, project2_version, project2_recent, ...
>>needs project_name
>>you can even use different wiki engines per project.
>>
>>Your id scheme is simplier on the database level.
>>DB: phpwiki
>> tables: page (with group_id), version, recent, ...
>>needs group_id
>>just one engine and one database schema.
>>
>>Pro: * You only have to do structure updates once,
>> and use a new primary index: pagename+id
>> * easier to upgrade to a new phpwiki schema and version.
>>Cons: * Seperation into different wiki's is hard.
>> * you cannot do project specific phpwiki updates.
>> * will not by supported by phpwiki OOTB.
>> So gforge sites must patch the WikiDB backends.
>>
>>I cannot accept your page.group_id patch into phpwiki.
>>It is way to abusive.
>>
>>
>>>Current state seems to work (around 1 month of tests without any
>>>problems) but I prefer waiting for phpwiki 1.3.11 release before release
>>>the plugin.
>>
>>The sql schema will not change anymore for sure.
>>Maybe some minor issues with exotic backends have to fixed.
>>
>>Major goals are only the request enhancements in main and Request
>>(GET => POST for ModeratedPage, maybe edit), check remaining request
>>problems (session, edit + redirect)
>>wikiparser fixes for php5 (or output?),
>>some remaining theme updates
>>configurator for lists
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Arnaud F. <ar...@cr...> - 2005-01-08 13:12:53
|
Manuel VACELET a écrit : > Reini Urban wrote: > >> I'll have a look after 1.3.11 but I still see no technical reason, why >> this should be better than tablename prefixes. Merging all the >> seperate table sets into one big mess... > > > I agree, it's not technical reasons. > I just "fell" it not very elegant (tables multiplications). Well ... your sql server will try to load the full table in memory. If it's too big, it won't be able to. With more smaller tables, that means more "context switching" ... but more chance to have the "current" table fully loaded in memory ... On a single very big table for your wiki farm, you'll also have bigger indexes to load, etc, etc ... that means slower operations. You should benchmark the two solutions with some real life data ... -- Arnaud Fontaine CRAO Jabber: sh...@ra... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X