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,
-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
The rule of normaliztation is (usually) if you have data repeated in a table,
you need another table. So here's how *I* would do it.
A table for each: DJ's, Albums, Artists, Genres (a category table of sorts),
and Tracks. You might even want a table for record companies, so that's not
Ben Bleything wrote:
Hello all!
I have a question for all of you... I would very much appreciate your
input.
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
On 28-Jul-2001 Ben Bleything wrote:
Hello all!
I have a question for all of you... I would very much appreciate your
input.
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
When you are designing a database and you are thinking about creating a
comma delimted list, this is a good sign that you need to rethink your
design. Bitfields are a good option, however if you ever need to add
elements to the bitfield (ie bitfield A can signify the presence of 4
elements, but
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
