Unikaj zerowalnych „kluczy obcych”. Mają wiele wad.
Ograniczenie w wierszu odniesienia nie zawsze jest egzekwowane, gdy klucz obcy zawiera wartość null. Jednak to domyślne zachowanie nie jest spójne między różnymi systemami DBMS. Niektóre DBMS obsługują opcje konfiguracji do zmiany zachowania dopuszczalnych kluczy obcych, a niektóre nie. Deweloperzy i użytkownicy SQL mogą więc nie wiedzieć, co tak naprawdę oznacza zerowe ograniczenie klucza obcego z punktu widzenia integralności danych. Przeniesienie bazy danych między produktami DBMS lub nawet między różnymi serwerami korzystającymi z tego samego produktu może dawać niespójne wyniki.
Narzędzia do projektowania baz danych, narzędzia integracyjne i inne oprogramowanie nie zawsze obsługują je poprawnie, a uzyskiwane wyniki mogą być nieprawidłowe.
Klucze obce są często używane w sprzężeniach i innej logice zapytań, co komplikuje problemy użytkownikom, którzy uważają, że ograniczenie obowiązuje, gdy go nie ma lub nie znają logiki stosowanej przez dany system DBMS.
Niektóre funkcje optymalizacji zapytań, które umożliwiają przepisywanie zapytań i inne optymalizacje, mogą być niedostępne, gdy klucz obcy ma wartość zerową.
Z logicznego punktu widzenia nullowalne ograniczenie „klucza obcego” nie ma większego logicznego sensu. Zgodnie ze standardem SQL takie ograniczenie nie może zostać naruszone, nawet jeśli tabela, do której następuje odwołanie, jest pusta. Jest to sprzeczne z jednym z najczęstszych domniemanych uzasadnień użycia wartości zerowej - że reprezentuje przypadek „nieznany”. Jeśli nie ma prawidłowych wartości X, to każdy „nieznany” X z pewnością nie może być prawidłową wartością - a jednak SQL na to zezwala.
Klucze obce dopuszczające wartości zerowe są całkowicie niepotrzebne. Zawsze możesz albo rozłożyć klucz obcy na nową tabelę, albo użyć wzorca nadtypu / podtypu, aby wartości zerowe nie były potrzebne. W trosce o prostotę i dokładność lepiej jest zatem pozostawić wartości zerowe niż je wstawić.