From: | "Todd Kennedy" <todd(dot)kennedy(at)gmail(dot)com> |
---|---|
To: | Joe <svn(at)freedomcircle(dot)net> |
Cc: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Question about One to Many relationships |
Date: | 2006-03-24 18:36:44 |
Message-ID: | 226d83de0603241036n3795047fy412f076f23f7be1c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
We're not concerned with the track info. This is a listing of album
information, hence the one to many relationship between the album and
the artist.
and for the record, i should correct myself. he said it was "bad" not "wrong".
but i hadn't given him all the details.
But. Yes. Thank you all for your help.
On 3/24/06, Joe <svn(at)freedomcircle(dot)net> wrote:
> Todd Kennedy wrote:
> > They haven't responded me as of yet. There should be a band associated
> > with each album -- this is handled in code, but other than that this
> > is the only relational db way I can think of to do it.
>
> But if a band can have songs in many albums and an album can have songs
> from multiple bands, it's a many-to-many relationship, NOT one-to-many.
> Short of the full track design suggested by PFC, you'd normally
> implement a many-to-many table as follows:
>
> CREATE TABLE bands_on_album (
> band_id integer REFERENCES band (id),
> album_id integer REFERENCES albums (id),
> PRIMARY KEY (band_id, album_id)
> )
>
> This of course precludes the same band being listed twice in a given
> album. If you do need that info, then you're really asking for "tracks".
>
> Joe
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2006-03-24 18:42:44 | Re: Question about One to Many relationships |
Previous Message | Joe | 2006-03-24 18:34:34 | Re: Question about One to Many relationships |