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.