When to have multiple tables
| From: | Digital Hit Entertainment | Date: | Wed, 12 Jul 2000 18:20:50 +0000 |
| Subject: | When to have multiple tables | ||
| Groups: | php.db | ||
| Request: | Send a blank email to php-db+get-1082@lists.php.net to get a copy of this message | ||
I'm still getting used to working with databases and PHP but I have been
able to script a news application for my site.
I'm now getting ready to work on a database that will track award
winners and nominees. I'm still not entirely sure when it's best to use
multiple tables and relational concepts and I'm also wondering what
method would be the most efficient to code via PHP.
The average awards track the following info:
YEAR
CATEGORY
STATUS <--nominee or winner
NAMES(S) <--single in the case of actors, directors, multiple for crafts
like editing, song
TITLE
ORDER <--Best Movie comes before Best Actor, so alphabetical doesn't
work, so I figure I assign each category with an order of importance
from say 1 to 5 and sort alphabetically by category within that e.g.
Best Movie=1 Best Director=2 Best Actor/Actress/Supporting=3, the
technical awards=4, the special awards (humanitarian,lifetime)=5
Things like categories can change names, disappear, merge, etc over the
years, so perhaps category should be in one table along with year and an
ID# and the other table would have year, id# and the other fields.
My ultimate concept of speeding the presentation would be to have:
$Category
<ul>
<li>$nominee for $title
<li>$nominee for $title
<li>$nominee for $title
</ul>
etc. and I could generate the pages for each year just by changing the
$year variable at the top. I could test for status and use an IF
statement to change winners to <li><b>$nominee for $title</b>
Thanks for letting me think out loud. If you have any comments or
suggestions I'd appreciate them. Links to good pages on relational
database design would also be appreciated.
Thanks.
--
Ian Evans