Re: Question about One to Many relationships

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
>
>

In response to

Browse pgsql-sql by date

  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