Getting back to the original posting, I'm basically saying that I don't think it's a good idea to structure or restructure a database for the sake of simplifying a few SQL statements. Especially if the data being joined is in separate tables for a good reason.
Regarding optimizing for programmer/bug-fixer/etc, after thinking about it, I realized that what constitutes "optimization" really depends a lot on your development situation, so I'll refrain from further comments on that. I probably shouldn't have brought it up, sorry.
cheers,
Travis
Michal Migurski wrote:
Up what creek? You didn't really provide any technical justification for your suggestion.
Up the creek of having to call for help on php-general because you have 24 identical tables you need to join, having never performed a join before.
The "pain" only occurs when writing the SQL statements to join the tables. I don't think it's a good idea to optimize the database schema for the sake of the programmer, who only has to write the SQL one time.
I wholeheartedly disagree. :) I think that optimizing for the sake of the programmer, the bug fixer, and the possible inheritor of the project is a /great/ idea. Servers keep getting faster, while the human attention span and rate of familiarization with code stays approximately constant, so optimizing your development time is at least as sensible as optimizing SQL select performance, which is probably better handled through well-chosen indexes anyway.
Optimizing for the programmer usually translates into thinking about the humans who will need to interpret your code, and making it easy to pick up the gist of your intent. A 24-table join is not a typical characteristic of what I'd consider a well-planned DB schema, whose meaning can be quickly grokked by a newcomer to the project.
If all those 24 tables store the same kind of data, then there's no reason to split them up. Of course, we haven't seen the specific usage of those tables in this thread, but I'm basing my posts on the assumption that it's better for the OP to have a "marbles" table with a "color" column, than tables named "red_marbles", "blue_marbles", 'green_marbles," etc. If that's not the kind of data we're talking about, then I stand corrected, and John Nichel's initial response is all that's needed.
A huge table count is often evidence of a need for some refactoring.
--------------------------------------------------------------------- michal migurski- contact info and pgp key: sf/ca http://mike.teczno.com/contact.html
-- Travis Low <mailto:[EMAIL PROTECTED]> <http://www.dawnstar.com>
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
