Re: Database Design Issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Jason Lange" <jslange@myrealbox.com>

> Here's my question. I'm creating a website for a weekly radio show. One
> of the items I would like to store in the database is the list of songs
> played in each show (there's normally between 20-25 songs per show), and
> the songs will be displayed by show. Should I put all of the songs in a
> single table with a field denoting what show they're from, or should I
> create a separate table for each weeks show and just request that entire
> table? I'm looking at this from both a long-term performance and
> *maintenance* issue.

The first question is if songs can span multiple shows? If so, you need 3
tables. One to hold the songs, each song getting a unique id. One table to
hold the shows, each show getting a unique id, and finally a third table
that relates the two. You'd list the song_id and the show_id that it's used
in. Add in a row for each song used in each show.

If a song is not shared across shows, then you could go with two tables. A
show table where each show gets a unique id and a song table with a column
that has a show_id in it relating it to what show it's used in.

You'd be better off with the first method, though, because sooner or later
down the line there's going to be a song shared, I imagine. :)

---John Holmes...


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux