i SQL är begreppet främmande nycklar en viktig som finns i alla professionella databaser som används i branschen. Kärntanken är att förhindra att din PostgreSQL-databas lagrar inkonsekventa data genom att genomdriva begränsningar som säkerställer att dina tabeller är korrekta (åtminstone när det gäller relationer mellan objekt). Referensintegritet är därför ett av de viktigaste begreppen som någonsin uppfunnits i den.

utländska nycklar kommer dock att introducera några problem som du måste ta hand om när du skriver applikationer. Om det inte finns några främmande nycklar kan du infoga data i valfri tabell i valfri ordning. PostgreSQL bryr sig inte. Men om en utländsk nyckel är på plats börjar ordningen att betyda (åtminstone i ett typiskt scenario men mer om det senare).

utländska nycklar och order

för att visa vikten av order måste vi först skapa en datamodell:

vi vill lagra valutor, produkter och produktbeskrivningar. I grund och botten är det en mycket enkel datamodell. Låt oss se om vi råkar infoga i produkttabellen:

logiskt kommer den första insatsen att misslyckas eftersom valuta nummer 1 inte existerar än. Om vi vill infoga måste vi använda ett NULL-värde (= okänd valuta). För ord: vi måste fylla valutatabellen först, sedan infoga platser, och så vidare. Ordern spelar roll i standardfallet.

bestämma rätt insättningsordning för främmande nycklar

om du måste börja använda en befintlig datamodell kan det vara lite svårt att linda huvudet runt det här. Att fylla i en tom datamodell kan vara lite knepigt. Så varför inte skriva en fråga som berättar för oss i vilken ordning vi ska infoga data?

Tja, här är den magiska frågan …

frågan är inte trivial att läsa, men jag har gjort mitt bästa för att dokumentera det lite. I grund och botten har PostgreSQL-systemtabellerna all information vi behöver för att bestämma rätt ordning. Här är utgången:

 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 frågan korrekt gett oss tabellerna i önskad ordning. Först måste vi infoga i alla tabeller på nivå ett och så vidare. Om vi håller oss till denna ordning kommer referensintegritet alltid att säkerställas (förutsatt att uppgifterna är korrekta).

att använda sig av” initialt uppskjutna ” begränsningar

i vissa fall kan insättningsordningen vara en otäck sak att hantera. Vad händer om vi hade möjlighet att berätta för PostgreSQL att ignorera ordern och kontrollera integriteten på commit istället? Detta är exakt vad ”initialt uppskjuten” gör. Så här fungerar det:

i det här fallet kan vi ändra data i vilken ordning vi vill. Så länge integriteten garanteras vara intakt i slutet av transaktionen är PostgreSQL helt bra. PostgreSQL kommer att skjuta upp begränsningskontrollen och ta lite börda av utvecklaren.

slutligen …

om du vill lära dig mer om avancerad SQL kanske du vill ta en titt på min blogg om några mer avancerade fönsterfunktioner (med band). Så ta på dig slipsen och Läs för att lära dig mer.

Lämna ett svar

Din e-postadress kommer inte publiceras.