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
This said, I mostly work with either Oracle or MS-SQL so mysql can still
problems. ( I always was a bit shy of using mysql as it didn't support a lot
functions that IMOH should be in a real db, like transactions and Ref
but that seems to have changed nowadays)
> -----Oorspronkelijk bericht-----
> Van: John S. Huggins [SMTP:[EMAIL PROTECTED]]
> Verzonden: Saturday, July 07, 2001 12:31 AM
> Aan: [EMAIL PROTECTED]
> 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
> 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?
> Divide and conquer?
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]