Jeżeli kolumna kolor w tabeli samochody ma przyjmować wyłącznie wartości ze słownika (tabeli referencyjnej) lakier, to problemem jest ograniczenie dopuszczalnych wartości do tych, które faktycznie istnieją w tabeli słownikowej.
W relacyjnych bazach danych standardowym mechanizmem zapewniającym taką spójność jest integralność referencyjna, realizowana przez klucz obcy (FOREIGN KEY). Klucz obcy jest ograniczeniem na kolumnie/kolumnach tabeli podrzędnej (tu: samochody), które wymusza, że każda zapisana wartość musi mieć odpowiadający rekord w tabeli nadrzędnej (tu: lakier). Dzięki temu nie da się wprowadzić "zielonyyy" ani innego koloru, którego nie ma w słowniku.
Od strony SQL zwykle robi się to poleceniem DDL modyfikującym schemat, np. w stylu:
ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);
(Dokładna składnia i nazwy kolumn zależą od DBMS, ale idea jest ta sama: kolumna w "samochody" wskazuje na klucz w "lakier").
Dlaczego pozostałe typy rozwiązań bywają błędnym wyborem w takim pytaniu?
- JOIN w SELECT "łączy" tabele tylko na czas odczytu danych, ale nie tworzy relacji/ograniczenia w schemacie i nie blokuje wpisania wartości spoza słownika.
- UPDATE/INSERT mogą kopiować lub poprawiać dane, ale nie wprowadzają stałej reguły walidacji na przyszłość.
- Indeks może przyspieszać wyszukiwanie, lecz nie wymusza, by wartość istniała w tabeli słownikowej.
W praktyce (aplikacje webowe, panel administracyjny) klucz obcy jest ważny, bo zabezpiecza dane nawet wtedy, gdy w aplikacji pojawi się błąd walidacji lub ktoś zapisuje dane innym narzędziem niż UI.
