Czytałem najczęściej popełniane błędy w projektowaniu baz danych popełniane przez deweloperów pytania i odpowiedzi dotyczące przepływu stosu. Przy pierwszej odpowiedzi padło zdanie na temat łuku wyłącznego:
Łuk wyłączny jest częstym błędem, gdy tabela jest tworzona z dwoma lub więcej kluczami obcymi, przy czym jeden i tylko jeden z nich może mieć wartość inną niż null. Duży błąd. Z jednej strony utrzymanie integralności danych jest o wiele trudniejsze. W końcu, nawet przy integralności referencyjnej, nic nie stoi na przeszkodzie, aby ustawić dwa lub więcej z tych kluczy obcych (pomimo złożonych ograniczeń sprawdzania).
Naprawdę nie rozumiem, dlaczego ekskluzywny łuk jest zły. Prawdopodobnie nie zrozumiałem jego podstaw. Czy jest jakieś dobre wytłumaczenie na temat ekskluzywnych łuków?
źródło
alter table mytable add constraint myconstraint check ((col1 is not null and col2 is null and col3 is null) or (col1 is null and col2 is not null and col3 is null) or (col1 is null and col2 is null and col3 is not null))
. Nie lubię ekskluzywnych łuków, ale można je egzekwować ograniczeniem sprawdzania. Oczywiście ograniczenie FK musi być również obecne.W ekskluzywnych łukach nie ma nic złego. Po prostu egzekwuj odpowiednią regułę biznesową, używając ograniczenia sprawdzania. Większość głównych systemów zarządzania bazami danych obsługuje ograniczenia sprawdzania (Oracle, SQL Server, PostgreSQL). Jeśli używasz narzędzia do modelowania danych, istnieje duże prawdopodobieństwo, że Twoje narzędzie automatycznie wygeneruje kod w celu wdrożenia ograniczenia sprawdzania.
źródło
Ekskluzywny łuk jest bardzo przydatny w projektowaniu koncepcyjnym lub logicznym. Nie oznacza to, że musisz to wdrożyć. We wcześniejszym przykładzie projektant może zdecydować się na wdrożenie projektu z trzema tabelami. Jeden dla miejsca parkingowego, jeden dla pracownika i jeden dla serwisu technicznego.
źródło