Pole tabeli zamowienia, które przechowuje identyfikator klienta z tabeli klienci i służy do powiązania obu tabel relacją, to pole
A. klucza obcego.
B. indeksu pełnotekstowego.
C. typu logicznego.
D. klucza podstawowego.
Pole w tabeli zamowienia, które przechowuje identyfikator klienta z tabeli klienci, jest kluczem obcym. To właśnie klucz obcy służy do tworzenia relacji między tabelami, np. zamowienia.id_klienta wskazuje na klienci.id_klienta. Dzięki temu baza wie, że konkretne zamówienie należy do konkretnego klienta. W praktyce jest to podstawa relacyjnych baz danych i normalnego projektowania schematu, bo nie powielamy danych klienta w każdym zamówieniu, tylko zapisujemy jego identyfikator. Moim zdaniem to jedna z najważniejszych rzeczy do ogarnięcia w SQL, bo potem łatwiej rozumie się JOIN, integralność referencyjną i poprawne modelowanie danych. Dobra praktyka jest taka, aby klucz obcy wskazywał na klucz podstawowy lub unikalny w tabeli nadrzędnej oraz miał zgodny typ danych. Często dodaje się też ograniczenia typu FOREIGN KEY oraz reguły ON DELETE albo ON UPDATE, np. żeby nie dało się przypadkiem usunąć klienta, który ma zamówienia, albo żeby zmiana identyfikatora została poprawnie obsłużona. W realnych systemach sklepów internetowych bez kluczy obcych szybko robi się bałagan: zamówienia mogą wskazywać na nieistniejących klientów, raporty się rozjeżdżają, a aplikacja musi sama pilnować rzeczy, które baza potrafi kontrolować automatycznie.
W tym pytaniu łatwo pomylić pojęcia, bo wszystkie brzmią dość technicznie, ale pełnią zupełnie inne role w bazie danych. Klucz podstawowy to pole albo zestaw pól, które jednoznacznie identyfikują rekord w swojej własnej tabeli. W tabeli klienci takim polem może być id_klienta, a w tabeli zamowienia raczej id_zamowienia. Sam fakt, że w zamowieniach znajduje się identyfikator klienta, nie oznacza jeszcze, że jest to klucz podstawowy tej tabeli. Jedno zamówienie ma swój własny identyfikator, a identyfikator klienta służy do wskazania rekordu w innej tabeli. I to jest właśnie sens relacji.
Indeks pełnotekstowy dotyczy zupełnie innego problemu. Używa się go do szybkiego wyszukiwania w długich tekstach, na przykład w opisach produktów, treści artykułów albo komentarzach użytkowników. Nie służy on do reprezentowania powiązań między tabelami ani do pilnowania integralności danych. Można oczywiście indeksować kolumny używane w relacjach, bo poprawia to wydajność zapytań JOIN, ale indeks nie zastępuje klucza obcego. To częsty błąd myślowy: skoro coś przyspiesza wyszukiwanie po identyfikatorze, to pewnie tworzy relację. Nie, relację logiczną i ograniczenie referencyjne definiuje klucz obcy.
Typ logiczny przechowuje wartości prawda/fałsz, np. czy klient jest aktywny albo czy zamówienie zostało opłacone. Nie nadaje się do przechowywania identyfikatora klienta, bo identyfikator ma zwykle postać liczby całkowitej lub czasem UUID. Z mojego doświadczenia najlepiej zapamiętać to tak: klucz podstawowy identyfikuje rekord u siebie, klucz obcy wskazuje rekord w innej tabeli, indeks pomaga szybciej szukać, a typ logiczny opisuje stan tak/nie. W relacyjnych bazach danych to rozróżnienie jest naprawdę praktyczne, nie tylko teoretyczne.
Indeks pełnotekstowy dotyczy zupełnie innego problemu. Używa się go do szybkiego wyszukiwania w długich tekstach, na przykład w opisach produktów, treści artykułów albo komentarzach użytkowników. Nie służy on do reprezentowania powiązań między tabelami ani do pilnowania integralności danych. Można oczywiście indeksować kolumny używane w relacjach, bo poprawia to wydajność zapytań JOIN, ale indeks nie zastępuje klucza obcego. To częsty błąd myślowy: skoro coś przyspiesza wyszukiwanie po identyfikatorze, to pewnie tworzy relację. Nie, relację logiczną i ograniczenie referencyjne definiuje klucz obcy.
Typ logiczny przechowuje wartości prawda/fałsz, np. czy klient jest aktywny albo czy zamówienie zostało opłacone. Nie nadaje się do przechowywania identyfikatora klienta, bo identyfikator ma zwykle postać liczby całkowitej lub czasem UUID. Z mojego doświadczenia najlepiej zapamiętać to tak: klucz podstawowy identyfikuje rekord u siebie, klucz obcy wskazuje rekord w innej tabeli, indeks pomaga szybciej szukać, a typ logiczny opisuje stan tak/nie. W relacyjnych bazach danych to rozróżnienie jest naprawdę praktyczne, nie tylko teoretyczne.