RE: [PHP-DB] Distributed Tables vs. fewer Monster Tables

If I understand it correcty you now have N tables with a structure MessageID | XXXX | YYYY and want to combine all those tables in one table with a structure like ForumID | MessageID | XXXX | YYYY This should not be a problem for any real db when you have an index on forumID and MessageID. This said, I mostly work with either Oracle or MS-SQL so mysql can still cause problems. ( I always was a bit shy of using mysql as it didn't support a lot of functions that IMOH should be in a real db, like transactions and Ref integrity, but that seems to have changed nowadays) Robert Klinkenberg > -----Oorspronkelijk bericht----- > Van: John S. Huggins [SMTP:jhuggins@vanet.va.net] > Verzonden: Saturday, July 07, 2001 12:31 AM > Aan: php-db@lists.php.net > Onderwerp: [PHP-DB] Distributed Tables vs. fewer Monster Tables > > > I am putting the finishing touches on a forum program which has a direct > lineage (look and feel at least) to Matt Wright's WWWBoard perl script. > Remember that? > > Today I have one table per forum. The forums on my live test site are > huge. > > http://www.astronomy.net/forums/ > > I have long dreamed of combining all the messages into one big honking > table in MySQL and parse accordingly. I already know how to do this, but > wonder the following: > > - Will MySQL lookup performance suffer... much? > - Is this just not a good idea? > - Will this make MySQL just flat out quit? > > I have heard the hype behind MySQL being able to handle incredible amounts > of data with relative ease. I hear that MySQL does a good job when you > are doing mostly reads as is the case here. So far, I have had absolutly > no issues with MySQL and just love it. Thus, I am automatically biased. > > So what say you non-biased folks about data management for a multi-topic > forum where each forum has identical structure, but differ only in topic? > > Combine and simplify? > > or > > Divide and conquer? > > > John > >