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 <[EMAIL PROTECTED]> 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
>
>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
