Jump to content

Music Database design help!!


browno

Recommended Posts

Right, so if I have a ARTISTMAP for my 1 to many relationship then how do I join in my releases which was usually done by just artistid? Sorry!!!

 

ARTISTMAP

artistmap- bigint(20), unsigned, Key (Primary), auto_increment

soloid

bandid

 

BANDS

bandid - bigint(20), unsigned, Key (Primary), auto_increment

bandname – varchar(255)

placeformed – varchar(255)

dateformed – date

biography - longtext

interview – longtext

artistid - bigint(20), unsigned, Key (Primary), auto_increment

 

SOLOS

soloid - bigint(20), unsigned, Key (Primary), auto_increment

soloname - varchar(255)

dateborn - date

biography - longtext

interview – longtext

website - varchar (255)

artistimage - varchar(255)

[!--quoteo(post=335280:date=Jan 10 2006, 08:41 PM:name=fenway)--][div class=\'quotetop\']QUOTE(fenway @ Jan 10 2006, 08:41 PM) 335280[/snapback][/div][div class=\'quotemain\'][!--quotec--]

I don't understand the question.

If I have the above tables with the following, what do I replace artistid with?

 

RELEASES ?releaseid - bigint(20), unsigned, Key (Primary), auto_increment ?reltitle - varchar(255) ?format - enum ?label - varchar (255) ?datereleased - date ?credits - text ?description - text ?artwork – varchar (255) ?artistid - bigint(20), unsigned, Key (MUL)

[!--quoteo(post=335294:date=Jan 10 2006, 09:55 PM:name=fenway)--][div class=\'quotetop\']QUOTE(fenway @ Jan 10 2006, 09:55 PM) 335294[/snapback][/div][div class=\'quotemain\'][!--quotec--]

Why would you replace it with anything? You might have to make it a band_id instead, but otherwise, there's nothing wrong.

 

Can I make it accept both soloids and bandids? I thought it would have to be one or the other.

Thanks!

Well, if all artists have a band_id, then you might as well link it to artist_id, and find the band from there. Alternatively, you can put in whatever uid you want, and have a type field. Personally, I prefer the former, because it's better DB design.

[!--quoteo(post=335329:date=Jan 10 2006, 11:57 PM:name=fenway)--][div class=\'quotetop\']QUOTE(fenway @ Jan 10 2006, 11:57 PM) 335329[/snapback][/div][div class=\'quotemain\'][!--quotec--]

Well, if all artists have a band_id, then you might as well link it to artist_id, and find the band from there. Alternatively, you can put in whatever uid you want, and have a type field. Personally, I prefer the former, because it's better DB design.

 

My head hurts! If i have:

 

ARTISTMAP

artistmap- bigint(20), unsigned, Key (Primary), auto_increment

soloid

bandid

 

BANDS

bandid - bigint(20), unsigned, Key (Primary), auto_increment

bandname – varchar(255)

placeformed – varchar(255)

dateformed – date

biography - longtext

interview – longtext

website - varchar (255)

artistimage - varchar(255)

 

SOLOS

soloid - bigint(20), unsigned, Key (Primary), auto_increment

soloname - varchar(255)

dateborn - date

biography - longtext

interview – longtext

website - varchar (255)

artistimage - varchar(255)

 

then what do I do? Can you modify this one. I'm going crazy! THANK YOU!

What you should really do at this point is put in some dummy data and see how it all works together, or draw one of those annoying DB design diagrams, if that's your thing. It will be much easier to see it this way. However, to make a _final_ point, you simply have to decide logically whether or not bands -OR- artists have releases, and based on that, put the appropriate FK in the releases table. I think you can take it from here -- especially after 32 posts; good luck.

  • 7 months later...
Hello ... no one posted in this topic for at least 30 days, I'm also designing a DB for localbands but this DB will only englobe metal bands ... and there are lots of styles inside metal music category.

Anyway an idea for your DB is that you could have the table BANDS and if there is just one member then it is still a band.

Now ... I'm just going to start with this other idea of database i hope you guys are stilling around to give me a hand .. bye

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.