So you're saying like this...?

Albums
------
ID,Artist,Title,Label

Tracks
------
Title,Length,TrackNumber,AlbumID

Where there is one album table and one track table, and each track
references back to the album that it is a member of?  I'm liking that...
It doesn't make it easy to dig through the database by hand, but in all
likelihood, nobody will ever need to do that.

Anybody think this is bad?

Thanks for the help,
Ben

-----Original Message-----
From: Tim Wilde [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, July 28, 2001 3:30 PM
To: Ben Bleything
Cc: [EMAIL PROTECTED]
Subject: Re: Sort-of theoretical db design question

> 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

Reply via email to