Sig, at jeg har følgende ER-diagram:
Nu hvis jeg repræsenterede forholdet ved hjælp af en fremmed nøgle på School i Student kunne jeg have NULL værdier (fordi en Student er ikke forpligtet til at tilhøre en School), for eksempel:
Så den korrekte måde (baseret på hvad jeg har læst) er at oprette en skæringstabel for at repræsentere forholdet, for eksempel:
Denne måde, ingen NULL værdier kan være til stede i tabellen School_has_Student.
Men hvad er ulemper ved at bruge en ugyldig fremmed nøgle i stedet for at oprette en skæringstabel?
Rediger:
Jeg valgte fejlagtigt (school_id, student_id) til at være den primære nøgle til School_has_Student -tabellen, som gjorde forholdet mange-til-mange. Den korrekte primære nøgle skulle have været student_id:
Kommentarer
- Der ‘ s er ingen ” korrekt ” måde. Der er ‘ den måde, der er bedst til dine behov.
- Jeg er enig med Doc om den falske forudsætning, men måske er det ‘ er stadig klare nok til at svare?
- Der er en falsk forudsætning, men det er let nok at rette op på og forklare forskellen.
- Jeg trak min nære stemme tilbage. , men sætningen ” Så den rigtige måde (baseret på hvad jeg har læst) er at oprette en skæringstabel for at repræsentere forholdet ” giver mig indtryk af, at du skal fortælle os, hvilken strammekilde der har fortalt dig, at dette er ” korrekt ” måde. I hver lærebog, jeg har læst før, er den kanoniske måde for 1: n-forhold en enkelt fremmed nøgle. Eller misforstod du noget?
- @Doc Brown Jeg kan ikke ‘ husker ikke, hvor jeg har læst det, men jeg er sikker på, at der står, at der var en krydstabel den rigtige måde. Uanset hvad, kan du give mig navnet på en bog, der siger, at et 1: n-forhold (med valgfri deltagelse på: 1-siden) skal repræsenteres ved hjælp af en enkelt fremmed nøgle, jeg er interesseret i at læse, hvad de siger om dette emne.
Svar
De to modeller repræsenterer forskellige forhold.
Ved hjælp af en sammenføjningstabel , modellerer du et mange-til-mange forhold.
Ved at bruge en simpel fremmed nøgle modellerer du et en-til-mange forhold.
Ulempen ved en ugyldig fremmed nøglen er at være ude af stand til at modellere forholdet så mange-til-mange, hvis det er det, du prøver at opnå.
Baseret på din redigering af spørgsmålet deler du effektivt elevtabellen i to tabeller med samme nøgle. Jeg ser det generelt på borde, der har alt for mange felter, så nogen deler dem i to for at være mere håndterbare (jeg kalder det at lægge læbestift på en gris).
Ved at opdele elevbordet laver du den anden tabel valgfri, fordi en post ikke behøver at eksistere i den anden tabel. Hvilket svarer meget til et felt, der ikke behøver at blive indstillet, fordi det kan være nul.
Hvis du vil have et forhold mellem mange, har du det bedre med at bruge en enkelt tabel og tillade skole-idet at være nul i elevtabellen. Der er ingen grund til at undgå nuller i felter, selv for en fremmed nøgle. Det betyder, at det udenlandske forhold er valgfrit: udviklere og DBAer forstår det klart, og den underliggende databasemotor burde helt sikkert fungere fint.
Hvis du er bekymret for sammenføjninger, skal du ikke bekymre dig. Der er veldefineret semantik for, hvordan sammenføjninger fungerer med null-felter. Ved at bruge en enkelt tabel kan du deltage i to tabeller i stedet for tre.
Kommentarer
- Så hvis jeg modellerer et forhold mellem mange og mange (med valgfri deltagelse på: 1-siden), skal jeg bruge en fremmed nøgle på trods af at den kan have
NULLværdier? - @Tom ja, det er nøjagtigt, hvordan man modellerer det. Mens det er teknisk muligt at bruge en tilslutningstabel, tillader datamodellen mange for mange, så du får brug for udløsere og databaselogik for at forhindre det. Du har det bedre ved at begrænse forholdet på en måde, så det er umuligt at tilføje forkerte data.
- Jeg redigerede til mit spørgsmål.Jeg lavede kun
student_idtil en primær nøgle i tabellenSchool_has_Student, som holdt forholdet som en-til-mange. Hvilke ulemper har denne metode ved at bruge en fremmed nøgle? - @Tom Jeg redigerede mit svar.
Svar
Du skrev i en kommentar ovenfor:
bogen “Fundamentals of Database Systems” […] siger [.. .] at det anbefales at bruge en krydsningstabel, hvis der er mange NULL-værdier i den fremmede nøglekolonne (for eksempel: hvis 98% af medarbejderne ikke administrerer en afdeling)
Når der er mange NULL-værdier i den fremmede nøglekolonne, skal dine programmer håndtere denne for det meste tomme kolonne for hver eneste post, de behandler. Kolonnen vil sandsynligvis optage noget diskplads selvom det i 98% af alle tilfælde er tomt, at spørge forholdet betyder forespørgsel til den kolonne, der giver dig mere netværkstrafik, og hvis du bruger en ORM, der genererer dig klasser fra dine tabeller, har dine programmer også brug for mere plads hos klienten side end nødvendigt. Brug af en inters sektionstabel undgår dette, der vil kun være linkregistreringer, der er nødvendige, hvis den tilsvarende udenlandske nøgle ellers ikke ville være NULL.
Modsat det, hvis du ikke kun har et par NULL-værdier, kan vi sige 50% eller mere forhold er ikke NULL, ved hjælp af en skæringstabel giver dig den modsatte effekt – mere diskplads, højere kompleksitet, hvilket resulterer i mere netværkstrafik osv.
Så brug af en skæringstabel er bare en form for optimering, kun fornuftig for en bestemt sag, og især i dag, hvor diskplads og hukommelse blev billigere, meget mindre hyppigt nødvendigt. Bemærk, at “Fundamentals of Database Systems” oprindeligt blev skrevet for mere end 20 år siden (jeg fandt en henvisning til den anden udgave fra 1994), og jeg antager, at den anbefaling allerede var derinde på det tidspunkt. Før 1994 var pladsoptimering sandsynligvis meget vigtigere end i dag, da masselagring stadig var dyrere, og computere og netværk var meget langsommere end i dag.
Som en sidebemærkning til en kræsen kommentar: ovenstående erklæring forsøger bare at foregribe, hvad forfatteren af “Fundamentals of Database Systems” havde i tankerne med sin anbefaling, jeg antager, at han fremsatte en grov, generel erklæring, der er gyldig for de fleste systemer. I nogle databaser er der andre mulige optimeringer som “sparsomme kolonner”, der gør brugen af en skæringstabel endnu mere forældet.
Så ikke få den anbefaling forkert. Bogen fortæller ikke du foretrækker krydsningstabeller til {0,1}:n -forhold generelt, eller – som du skrev – at dette er den “korrekte måde”. Brug optimeringer som dette, som kun gør dine programmer mere komplicerede, når du har virkelig brug for dem.
Kommentarer
- Du ‘ antager meget om implementeringen af database, især i betragtning af OP nævnte ‘ ikke en bestemt. Det ‘ er mere end sandsynligt, at databasen er smart nok til at bruge kun en lille mængde plads til sparsomme kolonner.
- @ gardenhead: hvad får dig til at tro, at dette er ” mere end sandsynligt “?
- Det faktum, at databaser har har eksisteret i årtier og er meget optimeret, da de er en kritisk komponent i de fleste infrastrukturer.
- @ gardenhead: lyder for mig, du laver meget uberettigede antagelser end mig. Ikke desto mindre se min redigering.
Svar
Konceptuel model vil se sådan ud, som er meget uortodoks for at sige det mindre:
Fysisk model vil se sådan ud, hvilket er forvirrende for at sige mindre (folk vil tro det er M: M, medmindre de ser nøje):
Mit forslag:
Hvis du har lignende, mange kolonner (FK eller andet), der ikke gælder for de fleste studerende, skal du adskille tabellerne i rolletabeller med 1: 1 rels. Men det er ikke fordi de er FK, det skyldes, at kolonnerne ikke gælder for de fleste rækker.
Ellers , nullable FK er en normal del af en database, og sammenføjningstabeller er normalt for M: M rels.
Almindelige anvendelser af 1: 1 rels er til rolletabeller med kolonner, der kun gælder, hvis enheden er af en bestemt type, og udpakning af BLOB-kolonner af hensyn til ydeevne eller opbevaring. Undgå nulværdier i FKer er ikke en almindelig anvendelse til det.
Svar
Ud over andre svar vil jeg gerne påpege, at en nulværdi for den fremmede nøgle er tvetydig. Betyder det:
1) Den studerendes skole (hvis nogen) er ukendt (dette er standardbetydningen af “null” – værdien er ukendt)
2) Det er vidste, om eleven har en skole eller ej, og de har ingen
Hvis du bruger standardbetydningen null, hvordan ville du repræsentere “elever har ingen skole” i din udenlandske nøglemodel? du bliver sandsynligvis nødt til at oprette en “ingen skole” -post med dens eget id i skoletabellen. (Ikke ideel)
Kommentarer
- Bogen ” Fundamentals of Database Systems ” nævner, at der er 3 fortolkninger af
NULL, det kan betyde: 1) Ukendt værdi. 2) Ikke tilgængelig eller tilbageholdt værdi. 3) Ikke relevant attribut (jeg tror denne fortolkning betyder, at du kan angive enNULLfor en fremmed nøgle). - At ‘ er en nyttig liste, men semantikken for null (eller en hvilken som helst værdi virkelig) er brugerdefinerbar. Det vil sigekan betyde hvad designeren siger, det betyder, ikke begrænset til denne liste. Spørgsmålet er, hvordan man skelner mellem forskellige betydninger, når der kræves mere end en (eller endda gemt utilsigtet)
- Så foreslår du, at jeg skal oprette en krydsningstabel i stedet for at bruge en ugyldig fremmed nøgle?
- @Tom Ja, jeg tror, det er bedre i dette tilfælde
- @BradThomas – for at undgå den samme tvetydighed ved brug af en krydsningstabel, ville du repræsentere sag 2 (det vides, at den studerende har ingen skole) ved en post i skæringstabellen med et NULL School_ID?
Svar
Databasetabeller har dette dejlig ting kaldet begrænsninger. Så det er meget let at lave i krydstabellen, der kun tillader 1 af hver elev at vises i tabellen, men mange skoler i tabellen. Effektivt at give dig en
Teori er god, men i sidste ende er du vil modellere din database efter de spørgsmål, du stiller.
Hvis du ofte vil stille spørgsmålstegn ved spørgsmålet: “hvilke elever der er i min skole” vil du virkelig spørge hele eleverstabellen eller have en let krydsningstabel.
I databaser: Optimer til de spørgsmål, du stiller.
Svar
Der er en brugssag, hvor brug af en tredje tabel faktisk kan give mening. Eksemplet kan virke rent hypotetisk, men jeg håber, det illustrerer min pointe godt. Lad os antage, at du tilføjer flere kolonner til students -tabellen, og på et eller andet tidspunkt beslutter du at håndhæve postenes entydighed via sammensat indeks i flere kolonner. Det er meget sandsynligt, at du “Jeg skal også inkludere kolonnen school_id, og her begynder ting at blive rodet. På grund af den måde, SQL blev designet, indsatte flere identiske poster, hvor school_id er NULL vil være mulig. Det giver fuld mening fra et teknisk perspektiv, men er kontraintuitivt og kan føre til uventede resultater. På den anden side håndhæver det unikke på krydstabellen er let.
Jeg var nødt til at modellere et sådant “valgfrit” forhold for nylig, hvor kravet om en unik begrænsning skyldtes en tidsstempelkolonne. At lade den nulbare fremmednøgle i tabellen pludselig føre til mulighed for at indsætte poster med samme tidsstempel (lad os antage, at det er en standard, indstillet på poster, der ikke er blevet revideret / appr oved endnu) – og den eneste udvej var at fjerne den ugyldige kolonne.
Så som du kan se, er det en ret specifik sag, og som andre bemærkede, ville du oftest være helt ok med alle NULL -værdierne. Det afhænger virkelig af de specifikke krav til din model.
Svar
Ud over de mange gode forslag, der allerede er sendt, personligt “Jeg er ikke fan af fremmede nøgler, medmindre de virkelig er nødvendige. Først er der M: M-forholdet, som du henviser til. Plus, at kalde en fremmed nøgle og derved trække tabeldataene ind i dine forespørgsler, introducerer mere kompleksitet og afhængigt tabelstørrelse, langsommere ydeevne. Som andre har sagt, kan nullede FK-felter ikke understøttes og kan skabe dataintegritetsproblemer.
Hvis du definerer en tilstand, hvor elevskolen er ukendt eller tom, er NULL vil ikke differentiere disse betingelser. (igen er vi tilbage til dataintegritet.) Rolletabelforslaget fra Tulains er elegant og giver mulighed for nulværdier rent.