w SQL pojęcie kluczy obcych jest ważne, które można znaleźć we wszystkich profesjonalnych bazach danych używanych w branży. Główną ideą jest zapobieganie przechowywaniu niespójnych danych w bazie danych PostgreSQL poprzez wymuszanie ograniczeń zapewniających poprawność tabel (przynajmniej jeśli chodzi o relacje między obiektami). Integralność odniesienia jest więc jednym z najważniejszych pojęć, jakie kiedykolwiek w niej wynaleziono.

jednak klucze obce wprowadzą pewne problemy, którymi należy się zająć podczas pisania aplikacji. Jeśli nie ma kluczy obcych, można wstawić dane do dowolnej tabeli w dowolnej kolejności. PostgreSQL ma to gdzieś. Jeśli jednak istnieje klucz obcy, kolejność zaczyna mieć znaczenie (przynajmniej w typowym scenariuszu, ale o tym później).

klucze obce i zamówienie

aby pokazać znaczenie zamówienia, musimy najpierw utworzyć model danych:

chcemy przechowywać waluty, produkty, a także opisy produktów. Zasadniczo jest to bardzo prosty model danych. Zobaczmy, czy zdarzy nam się wstawić do tabeli produktów:

logicznie pierwsza wstawka nie powiedzie się, ponieważ waluta numer 1 jeszcze nie istnieje. Jeśli chcemy wstawić, musimy użyć wartości NULL (=unknown currency). W kolejności słów: najpierw musimy wypełnić tabelę walut, następnie wstawić lokalizacje i tak dalej. Kolejność ma znaczenie w przypadku domyślnym.

określenie prawidłowej kolejności wstawiania kluczy obcych

jeśli musisz zacząć korzystać z istniejącego modelu danych, może być ci trochę trudno ogarnąć te rzeczy. Wypełnianie pustego modelu danych może być nieco trudne. Dlaczego więc nie napisać zapytania informującego o kolejności wstawiania danych?

cóż, oto magiczne zapytanie …

zapytanie nie jest trywialne do przeczytania, ale zrobiłem wszystko, co w mojej mocy, aby je nieco udokumentować. Zasadniczo tabele systemowe PostgreSQL zawierają wszystkie informacje potrzebne do ustalenia właściwej kolejności. Oto wyjście:

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

jak widać, zapytanie poprawnie podało nam tabele w żądanej kolejności. Po pierwsze, musimy wstawić do wszystkich tabel na poziomie pierwszym i tak dalej. Jeśli będziemy trzymać się tej kolejności, integralność odniesienia będzie zawsze zapewniona (zakładając, że dane są poprawne).

Korzystanie z „początkowo odroczonych” ograniczeń

w niektórych przypadkach kolejność wstawiania może być nieprzyjemną rzeczą do czynienia. A gdybyśmy mieli środki, aby powiedzieć Postgresqlowi, aby zignorował kolejność i zamiast tego sprawdził integralność w commit? Właśnie to robi „początkowo odroczony”. Oto jak to działa:

w tym przypadku możemy zmodyfikować dane w dowolnej kolejności. Tak długo, jak integralność jest gwarantowana nienaruszona po zakończeniu transakcji, PostgreSQL jest całkowicie w porządku. PostgreSQL odłoży kontrolę ograniczeń i odciąży programistę.

wreszcie …

jeśli chcesz dowiedzieć się więcej o zaawansowanym SQL, możesz rzucić okiem na mój blog o bardziej zaawansowanych funkcjach okienkowania (z krawatami). Więc załóż krawat i Czytaj, aby dowiedzieć się więcej.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.