If I understand it correcty you now have N tables with a structure
MessageID | |
and want to combine all those tables in one table with a structure like
ForumID | MessageID | |
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:[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
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
--
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]
