Morgan Craft wrote:
If you are using DISTINCT probably means you need to normalize your data
and look to join more appropriately. Also for creating indexes you
really need to consider how you plan to access your data and how it will
be used - which goes back to properly normalizing database tables. With
properly structured tables you should be easily able to identify certain
relationships and know where to put indexes - preferably columns that
are used for JOINS and WHERE.
Good place to start:
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
Hope it helps
Thank you for that pointer. The three tables that I have are for
pictures. One table contains everything that revolves around the file
itself, such as storage location, rotation angle, addition and creation
dates. The second table has the name and description for the picture.
The third table holds all the categories that can be attached to a
single picture. And that table will have more than one row for each
picture, unless I limit assignment to one category, which is pretty useless.
OK, I could force one row and have a column for each category, but then
I set a hard limit on the maximum number of categories. With my approach
I can change the maximum number of categories in code without requiring
a different table structure. I can't see how I could reasonably
normalize that and keep the flexibility that I have now. What happens
when I want 10 categories today and 20 tomorrow and I do not want to add
more tables or change exisiting ones?
David
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
