> I'm building a database for a radio station. The database must allow
> the DJ to enter what they play and when, and allow the program director
> to create weekly reports for the record labels.
[snip]
> First, to maintain a single table with every bit of track data there is
> (ie, title, artist, length, etc) and store this data into the albums
> table via either a bitfield (ie, binary additions, etc) or via a comma
> (or other) delimited list... ie "32897,39823,1234,29844" etc.
Yeouch. I'm no huge database guru like I'm sure some people here are, but
that violates all kind of normalization (though it's necessary to do so
sometimes)
> The other thought would be to have an album table that would contain
> things like the label, artist, number of tracks, etc, and another table
> that would contain the track data for that album... ie "1238_tracks".
That seems like the way go go, but I get the impression you're saying one
table per album - that would be bad. My recommendation would be an albums
table - you might want to make a simple INT AUTO_INCREMENT column in that
table to be a unique ID (I tend to do that a little too much, but it might
be good in this case), then have a tracks table that's got a non-unique
key on the album_id, along with whatever data about the specific track you
want to store. That way you don't have to replicate very much
information, just that album_id.
Hope this input is useful.
Tim Wilde
--
Tim Wilde
[EMAIL PROTECTED]
Systems Administrator
Dynamic DNS Network Services
http://www.dyndns.org/
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
