Czym jest ekskluzywny arc w bazie danych i dlaczego ' jest zły?

O ile zrozumiałem to dawno temu, w ekskluzywnym arc tabela zawiera pewną liczbę kolumn, które są kluczami obcymi dla innych tabel, ale tylko jedna z nich może być ustawiona na raz (ze względu na pewne ograniczenia logiczne domeny wynikające ze świata rzeczywistego). Ponieważ tej reguły nie można wymusić w bazie danych, można utworzyć uszkodzony rekord, w którym więcej niż jeden z tych kluczy obcych ma wartość.

Zrobię przykład. Rozważmy aplikację, w której firma śledzi ciężarówki, których używa do dostarczania towarów. Ciężarówka może znajdować się tylko w jednym z trzech miejsc jednocześnie: może być z pracownikiem, może znajdować się na parkingu lub może być w sklepie konserwacyjnym. Można to wymodelować poprzez posiadanie tabeli Truck-table z EmployeeId, parkingGarageId i MaintenanceShopId, które odwołują się do tabel Employee, ParkingGarage i MaintenanceShop. Nie ma możliwości egzekwowania reguły, że tylko jedno z tych pól jest wypełnione na poziomie bazy danych. Zły kod lub ktoś, kto ma bezpośredni dostęp do bazy danych, mógłby wstawić rekord, który ma wypełnione dwa lub trzy pola, co jest równoznaczne z uszkodzeniem danych w bazie danych.

Komentarze

• Trzy możliwe lokalizacje ciężarówek są podklasami nadklasy, " lokalizacja ciężarówki ". Istnieje wiele przypadków, w których podklasy wzajemnie się wykluczają. Wyzwaniem staje się modelowanie klas i podklas w tabelach relacyjnych.
• Zgadzam się, że są przypadki, w których użycie tego projektu jest uzasadnione. Mogę jednak również zgodzić się z oryginalnym postem, że ten wzór jest używany DUŻO częściej niż powinien. Ma też bardzo duże wady …
• Czy nie można użyć ograniczenia sprawdzającego? Na przykład 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 ' nie lubię wyłącznych łuków, ale można je wymusić za pomocą ograniczenia sprawdzającego. Oczywiście musi istnieć również ograniczenie FK.
• Stąd " złożone ograniczenia kontrolne niezależnie od " z postu cytowane powyżej. Możesz być w stanie przeprowadzić naprawdę wyrafinowaną walidację z ograniczeniami sprawdzającymi lub do cholery, nawet wyzwalaczami, które ' nie sprawiają, że jest to dobry pomysł lub dowód dobrego projektu. Wyobraź sobie, że wykonujesz ograniczenia kontrolne na ekskluzywnych łukach z czterema lub pięcioma kolumnami … Poza tym ' jestem dość pewien, że nie wszystkie silniki baz danych obsługują ograniczenie CHECK . MySQL wyraźnie stwierdza w dokumentach, że klauzule CHECK są analizowane, ale ignorowane …
• To źródło zaleca wyłączność arc. Myśli?

Nie ma nic złego w ekskluzywnych łukach. Po prostu wymuś odpowiednią regułę biznesową za pomocą ograniczenia sprawdzającego. Większość głównych systemów zarządzania bazami danych obsługuje ograniczenia kontrolne (Oracle, SQL Server, PostgreSQL). Jeśli używasz narzędzia do modelowania danych, istnieje duża szansa, że narzędzie automatycznie wygeneruje kod w celu zaimplementowania ograniczenia sprawdzającego.

Ekskluzywny łuk jest bardzo przydatny w projektowaniu koncepcyjnym lub logicznym. Nie oznacza to, że musisz implementować w ten sposób. We wcześniejszym przykładzie projektant może zdecydować się na wdrożenie projektu z trzema tabelami. Jedna do parkowania lokalizacja, jedna dla pracownika i jedna dla warsztatu.