i KVL er begrebet udenlandske nøgler et vigtigt begreb, der findes i alle professionelle databaser, der bruges i branchen. Kerneideen er at forhindre, at din database lagrer inkonsekvente data ved at håndhæve begrænsninger, der sikrer rigtigheden af dine tabeller (i det mindste hvad angår forholdet mellem objekter). Referentiel integritet er derfor et af de vigtigste begreber, der nogensinde er opfundet i det.

udenlandske nøgler introducerer dog nogle problemer, som du skal passe på, når du skriver applikationer. Hvis der ikke er udenlandske nøgler, kan du indsætte data i en hvilken som helst tabel i en hvilken som helst rækkefølge. Postgraduate er ligeglad. Men hvis en fremmed nøgle er på plads, begynder ordren at gøre noget (i det mindste i et typisk scenario, men mere om det senere).

udenlandske nøgler og ordre

for at vise vigtigheden af ordre skal vi først oprette en datamodel:

vi vil gemme valutaer, produkter samt produktbeskrivelser. Dybest set er det en meget enkel datamodel. Lad os se, om vi tilfældigvis indsætter i produkttabellen:

logisk set vil den første indsats mislykkes, fordi valuta nummer 1 ikke findes endnu. Hvis vi vil indsætte, skal vi bruge en NULL-værdi (= ukendt valuta). For ord: vi skal først udfylde valutatabellen, derefter indsætte placeringer osv. Ordren betyder noget i standardsagen.

bestemmelse af den korrekte indsætningsrækkefølge for udenlandske nøgler

hvis du skal begynde at bruge en eksisterende datamodel, kan det være lidt svært at pakke hovedet rundt om disse ting. At udfylde en tom datamodel kan være lidt vanskelig. Så hvorfor ikke skrive en forespørgsel, der fortæller os, i hvilken rækkefølge vi skal indsætte data?

nå, her er den magiske forespørgsel…

forespørgslen er ikke triviel at læse, men jeg har gjort mit bedste for at dokumentere det lidt. Grundlæggende har postgraduate systemtabeller alle de oplysninger, vi har brug for for at bestemme den rigtige rækkefølge. Her er output:

 table_name | level-----------------+------- t_currency | 1 t_location | 1 t_product | 2 t_product_desc | 3 t_product_stock | 3(5 rows)

som du kan se, har forespørgslen korrekt givet os tabellerne i den ønskede rækkefølge. Først skal vi indsætte i alle tabeller på niveau et og så videre. Hvis vi holder os til denne ordre, vil referentiel integritet altid sikres (forudsat at dataene er korrekte).

brug af “oprindeligt udskudte” begrænsninger

i nogle tilfælde kan indsættelsesordren være en grim ting at håndtere. Hvad hvis vi havde midlerne til at fortælle Postgraduate at ignorere ordren og kontrollere integriteten på commit i stedet? Dette er præcis, hvad “oprindeligt udskudt” gør. Sådan fungerer det:

i dette tilfælde kan vi ændre data i den rækkefølge, vi ønsker. Så længe integritet er garanteret at være intakt i slutningen af transaktionen, er postgraduate helt fint. Postgraduate vil udsætte begrænsningskontrollen og tage en vis byrde af udvikleren.

endelig …

hvis du vil lære mere om Avanceret KVM, kan du tage et kig på min blog om nogle mere avancerede vinduesfunktioner (med bånd). Så tag dit slips på og Læs for at lære mere.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.