On Tue, Jan 07, 2003 at 03:58:35PM -0800, Brion Vibber wrote:
On mar, 2003-01-07 at 15:06, Tomasz Wegrzanowski
wrote:
On Tue, Jan 07, 2003 at 11:40:10PM +0100, Paul
Ebermann wrote:
So for each new language a new table. Why?
Doesn't a language field in one article table would be enough?
It should be faster that way, because locking issues on English tables
won't cause any problems for us.
And too many English articles won't cause selects to be any slower
for other languages that way.
I think a better approach is to make the system work more smoothly so
that neither the other languages _nor_ the English section have to
suffer from the English section's large number of articles.
Separate tables in the same database won't be any better than separate
databases on the same server, which presently causes problems because
the English tables will get locked up and additional requests get backed
up until the server hits its open connection limit -- then other
languages can't connect either, and you just have to wait it out.
Separate tables in single database is completely equivalent to separate
tables in separate databases (databases aren't real, tables are real).
I simply don't see any point in changing that.
Some "fair" system would be nice, with "other" languages having
higher
priorities than English ...
If we can iron out the locks, I believe a combined
table system will be
both more flexible and easier to program against.
That would be nice, but we should rather try to make minimal number of
changes necessary for given goal.
Having only 'interwiki' and 'users' common is enough, we can merge the
rest
later if it won't result in any performance problems.