> 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
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 no
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 wee
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 f
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
repeat
bject: 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 sing
> 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,
