mange-til-een?

ja - det var en oplagt opsplitning

overvej evt. et pladeselskabs id fremfor pladeselskabs navn

nej - fremmed noegle har intet med primaer noegle at goere

Hvis det er sandt at et band kan være hos et og kun et pladeselskab
og at et pladseselskab kan have mange bands, så er relationen
en en-til-mange relation med pladeselskab på en siden.

Tabellerne kan f.eks. se sådan ud:

tblBand
  BandID (PK)
  BandNavn
  ...
  PladeselskabID (FK)

tblPladeselskab
  PladeselskabID (PK)
  PladeselskabNavn
  ...

(PK) er primærnøgle (FK) er fremmednøgle

Takker for den prompte respons.

Hvis jeg laver et nummereringfelt, kommer deet samme selskab så ikke bare til at stå et utal af gange i tabellen?

Jeg har også lige en afsluttende detalje, jeg også gerne vil høre jer om.

Hvis jeg også laver en "person" tabel, hvor en person kan have flere roller distributør, VIP osv.), og også være med i flere bands, (M:M imellem "band" og "person") hvorledes skal jeg så designe i forhold til rollerne? Hvis en person har andre roller i organisationen end bare det at være bandmedlem- og måske også er medlem af mere end et band, må personen selvfølgelig ikke slettes før det sidste band han er tilknyttet til, slettes -og han iøvrigt heller ingen andre roller udfylder i organisationen. Hvordan designer jeg dette uden at komme galt afsted? man kan vist ikke bruge CASCADES I MySQL og triggers anbefaledes mig ikke.

Skal der være endu en E:M imellem en eventuel "person" og "rolle" tabel? Eller skal det være en M:M udfra logikken, at "en person kan have flere roller, og en rollebetegnelse kan deles af flere personer?" Informationen er boolsk "Yes" eller "no" og jeg er derfor blevet rådet til bare at putte et felt for hver mulig medlemsrolle i "bandmember" tabellen, da det ville være overkill (og måske ikke ladsiggørligt?) med en separat rolle tabel. Er i enige i det.

Tak.

MySQL understøtter cascade for InnoDB tabeller

Jeg tror at jeg vil fraråde person rolle modellen - det bliver hurtigt komplekst.

tblPerson
  PersonID (PK)
  PersonNavn
  ...

tblRolle
  RolleID (PK)
  RolleType
  ...

tblPerson_Rolle
  RolleID (FK)
  PersonID (FK)

I den sidste tabel kombinerer du en rolle med en person. En person kan
have mange roller og en rolle kan ligge hos mange personer.
Forholdet imellem person og rolle er altså mange-til-mange.

Eller på dansk: En person kan f. eks. være både musiker og booker
og der er f. eks. mange personer der kan være musikere.

Hvis du laver relationer imellem tabellerne, er det ikke muligt
at tildele en rolle til en person, hvis rollen ikke er oprettet
endnu og det er ikke muligt at slette en rolle, så længe der findes
en person der varetager denne rolle.

Med relationer vil databasen altid være konsistent.

Mange tak for det gode svar.

Det, der er det vigtige her, er at jeg kan nemt løbende kan tilføje eller slette personer fra eksisterende bands, og tilføje eller slette roller til/fra eksisterende personer uden ar ramle ind i konflikter relateret til utilstrækkeligt design, samt at  en person kan tilføjes organisationen uden at behøve at være medlem af et band. Hvis det kan lade sig gøre med den opstilling du foreslår, så tror jeg vi er ved at være der. Jeg kan så ved at følge logikken i det du iøvrigt glimrende forklarer, ffsoft - så regne ud, at en eventuel instrument tabel, også vil være en M:M til person tabellen.

Til allersidst: Anbefales det ikke normalt, at de to fremmednøgler i en brotabel i en M:M lægges sammen til en sammensat primær nøgle?

Ellers mange tak for info'en - meget brugbart.

Yep, en person kan spille på mange instrumenter og et instrument
kan spilles af mange personer. Altså en mange-til-mange relation.

tblPerson
  PersonID (PK)
  PersonNavn
  ...

tblInstrument
  InstrumentID (PK)
  InstrumentNavn
  ...

tblPerson_Instrument
  PersonID (FK)
  InstrumentID (FK)
  ...

Når dine tabeller er opbygget korrekt, d.v.s. afspejler virkeligheden
og er på 3 normalform (3NF), har du automatisk en hel række
fordele. Bl. a. at du er sikker at databasen altid er konsistent.
Du kan læse mere om hvorfor her: http://www.ffsoft.dk/eksempler.asp
under datamodellering.

Omkring sammensatte nøgler kender jeg en rigtig god regel:

Hvis man får lyst til at bruge en sammensat nøgle, (en nøgle som består
af mere end et felt), skal man slå sig selv i hovedet og det skal man
blive ved med, indtil lysten er væk. Men det er der selvfølgelig nogle
der vil være uenig i. Jeg har arbejdet med databaser i 15+ år og aldrig
haft brug for en.