Nullable Foreign Key Zła praktyka?

Załóżmy, że masz tabelę Zamówienia z kluczem obcym do identyfikatora klienta. Teraz załóżmy, że chcesz dodać zamówienie bez identyfikatora klienta (czy to powinno być możliwe, to inna kwestia), musiałbyś ustawić klucz obcy na NULL ... Czy to zła praktyka, czy wolisz pracować z tabelą połączeń między Zamówienia i klienci? Chociaż relacja wynosi od 1 do n, tabela połączeń spowodowałaby, że jest ona od n do n. Z drugiej strony, z tabelą linków, nie mam już tych wartości NULL ...

Tak naprawdę w bazie danych nie będzie zbyt wielu wartości NULL, ponieważ rekord z kluczem obcym do NULL jest tylko tymczasowo, do momentu dodania klienta do zamówienia.

(W moim przypadku nie jest to Zamówienie i Klient).

EDYCJA: A co z nieprzypisanym klientem, do którego można utworzyć łącze?

Posiadanie tabeli linków jest prawdopodobnie lepszą opcją. Przynajmniej nie narusza normalizacji BCNF (normalna postać Boyce-Codda). jednakże wolałbym być pragmatycznym. Jeśli masz bardzo mało tych wartości null i są one tylko tymczasowe, myślę, że powinieneś pominąć tabelę linków, ponieważ tylko zwiększa złożoność schematu.

Na marginesie; użycie tabeli połączeń niekoniecznie powoduje, że jest to n do n, jeśli w tabeli połączeń używasz klucza obcego wskazującego na tabelę zamówień jako klucza podstawowego w tej tabeli połączeń, relacja nadal wynosi 1..n. W tej tabeli łączy może znajdować się tylko jeden wpis na zamówienie.

Nie Nie ma nic złego w zerowych ZK. Jest to częste, gdy jednostka, na którą wskazuje FK, jest w relacji (zero lub jeden) do (1 lub wiele) z podstawową tabelą, do której odwołuje się klucz.

Przykładem może być sytuacja, w której w tabeli znajdował się zarówno adres fizyczny, jak i atrybut (kolumna) adresu pocztowego, z elementami FK do tabeli adresów. Możesz ustawić wartość zerową adresu fizycznego do obsługi, gdy jednostka ma tylko skrytkę pocztową (adres pocztowy), a adres pocztowy może być obsługiwany, gdy adres pocztowy jest taki sam jak adres fizyczny (lub nie).

Kolumny dopuszczające wartość null mogą znajdować się w przedziałach od 1NF do 5NF, ale nie w 6NF, zgodnie z tym, co przeczytałem.

Tylko wtedy, gdy wiesz lepiej niż Chris Date "co naprawdę oznacza pierwsza normalna forma". Jeśli x i y są dopuszczalne wartości null, a rzeczywiście w pewnym wierszu x i y są oba null, to WHERE x=ynie daje true. Dowodzi to ponad wszelką wątpliwość, że null nie jest wartością (ponieważ każda rzeczywista wartość jest zawsze sobie równa). A ponieważ RM nakazuje, że „musi istnieć wartość w każdej komórce tabeli”, każda rzecz, która prawdopodobnie zawiera wartości null, nie jest rzeczą relacyjną, a zatem kwestia 1NF nawet się nie pojawia.

Słyszałem, jak argumentował, że kolumny dopuszczające wartość zerową generalnie przerywają pierwszy stopień normalizacji.

Zobacz powyżej rozsądny powód leżący u podstaw tego argumentu.

Ale w praktyce jest to bardzo praktyczne.

Tylko jeśli jesteś odporny na bóle głowy, które zwykle powoduje w całej reszcie świata. Jednym z takich problemów (i to tylko nieznacznym, w porównaniu do innych nullzjawisk) jest fakt, że WHERE x=yw SQL faktycznie oznacza WHERE x is not null and y is not null and x=y, ale większość programistów po prostu nie jest tego świadoma i po prostu czyta. Czasami bez szkody, innym razem nie.

W rzeczywistości kolumny dopuszczające wartość null naruszają jedną z najbardziej fundamentalnych zasad projektowania baz danych: nie łącz różnych elementów informacji w jednej kolumnie. Wartości null robią dokładnie to, ponieważ łączą wartość logiczną „to pole jest / nie jest naprawdę obecne” z wartością rzeczywistą.

Nie widzę nic złego w tym, że jest to tylko opcjonalna relacja n-1, która będzie reprezentowana przez wartość null w kluczu obcym. W przeciwnym razie, jeśli umieścisz tabelę linków, będziesz musiał zarządzać tym, że nie stanie się ona relacją nn, co spowoduje jeszcze więcej problemów.

Relacje opcjonalne są zdecydowanie możliwe w modelu relacyjnym.

Możesz użyć wartości null, aby wyrazić brak relacji. Są wygodne, ale spowodują te same bóle głowy, które null powodują gdzie indziej. Jednym miejscem, w którym nie powodują żadnych problemów, jest dołączanie. Wiersze, które mają wartość null w kluczu obcym, nie pasują do żadnych wierszy w tabeli, do której się odwołuje. Więc wypadają z połączenia wewnętrznego. Jeśli wykonujesz łączenia zewnętrzne, i tak będziesz mieć do czynienia z wartościami zerowymi.

Jeśli naprawdę chcesz uniknąć wartości null (szósta normalna forma), możesz zdekomponować tabelę. Jedna z dwóch zdekomponowanych tabel zawiera dwie kolumny kluczy obcych. Jeden to opcjonalny klucz obcy, który posiadasz, a drugi to klucz obcy odwołujący się do klucza podstawowego oryginalnej tabeli. Teraz musisz użyć ograniczeń, aby zapobiec przekształceniu się relacji wiele-do-wielu, jeśli chcesz temu zapobiec.

Użycie wartości NULL byłoby dobrym sposobem na wyczyszczenie niekompletnych zamówień:

SELECT * FROM `orders`
WHERE `started_time` < (UNIX_TIMESTAMP() + 900) AND `customer_id` IS NULL

Powyższe pokaże zamówienia starsze niż 15 minut bez powiązanego identyfikatora klienta.

Jeśli dodajesz zamówienie tylko tymczasowo bez identyfikatora klienta do momentu zdefiniowania klienta, czy nie byłoby łatwiej dodać klienta i zamówienie w jednej transakcji, eliminując w ten sposób potrzebę wprowadzania klucza obcego NULL i unikając wszelkich ograniczeń lub wyzwalaczy ustawiłeś, że jesteś gwałcony?

Zwykle taka sytuacja ma miejsce w aplikacjach internetowych, w których zamówienie jest szczegółowo opisane, zanim klient określi, kim jest. W takich sytuacjach zamówienie jest utrzymywane w stanie serwera lub w pliku cookie do momentu dostarczenia całego stanu niezbędnego do pełnego zamówienia, w którym to momencie zamówienie jest utrwalane w bazie danych.

NULL klucze obce są w porządku dla rzeczy takich jak adresy, jak wspomniano powyżej. Ale pole klienta o wartości NULL nie ma sensu dla zamówienia i powinno być ograniczone.

Zawsze możesz dodać sztuczny wiersz do tabeli Customer, na przykład Id = -1 i CustomerName = 'Unknown', a następnie w przypadkach, gdy normalnie ustawisz CustomerId w Order NULL, ustaw go na -1.

Pozwala to na brak zerowych elementów FK, ale nadal odpowiednio reprezentuje brak danych (i uchroni Cię przed dalszymi użytkownikami, którzy nie wiedzą, jak radzić sobie z wartościami NULL).

Zerowalne elementy FK dla opcjonalnych relacji wiele do jednego są całkowicie w porządku.

Słyszałem, jak argumentowano, że kolumny z wartością zerową generalnie przerywają pierwszy stopień normalizacji. Ale w praktyce jest to bardzo praktyczne.

Tak, coś jest nie tak. Nie jest to klucz obcy, jeśli dopuszcza wartość null. Projekt bazy danych według kodu. Może utworzysz zerowy link do nieprzypisanych. lub „Nieprzypisane”, jeśli używasz znaku kol. Zachowaj 100% integralność danych.