Czy złą praktyką jest posiadanie kilku wzajemnie wykluczających się relacji jeden do jednego?

Powiedzmy, tabela carma relację jeden-do-jednego do tabel electric_car, gas_cari hybrid_car. Jeśli a carjest electric_car, nie może już pojawiać się w, gas_cara hybrid_caritp.

Czy jest coś złego w takim projekcie? Jakieś problemy, które mogą wystąpić na drodze?

Różne typy samochodów są przykładem ogólnego problemu, który pojawia się w modelowaniu danych w kółko. Nazywa się to „uogólnieniem / specjalizacją” w modelowaniu ER, a „superklasa / podklasa” w modelowaniu obiektowym.

Modeler obiektów korzysta z funkcji dziedziczenia wbudowanych w model obiektów, aby dość łatwo rozwiązać problem. Podklasy po prostu rozszerzają nadklasę.

Model relacyjny ma do czynienia z problemem. jak zaprojektować tabele, aby naśladować korzyści wynikające z dziedziczenia?

Najprostsza technika nazywa się dziedziczeniem pojedynczej tabeli . Dane o wszystkich typach samochodów są pogrupowane w jedną tabelę dla samochodów. Istnieje kolumna car_type, która grupuje wszystkie samochody jednego typu. Żaden samochód nie może należeć do więcej niż jednego typu. Jeśli kolumna nie ma znaczenia, powiedzmy, samochody elektryczne, pozostanie NULL w wierszach, które dotyczą samochodów elektrycznych.

To proste rozwiązanie działa dobrze w mniejszych i prostszych przypadkach. Obecność dużej liczby wartości NULL w niewielkim stopniu wpływa na ogólne obciążenie pamięci masowej i nieco na ogólne pobieranie. Deweloper może być zmuszony nauczyć się logiki trójwartościowej SQL, jeśli testy logiczne są wykonywane na kolumnach zerowalnych. Na początku może to być zaskakujące, ale można się do tego przyzwyczaić.

Istnieje inna technika, nazywana dziedziczeniem tabeli klas . W tym projekcie istnieją oddzielne tabele dla gas_car, electric_car i hybrid_car, oprócz połączonego stołu, car, dla wszystkich z nich. Jeśli chcesz uzyskać wszystkie dane dotyczące określonego rodzaju samochodu, dołącz do stołu samochodowego odpowiednim stołem specjalistycznym. W tym projekcie jest mniej wartości NULL, ale więcej łączysz. Ta technika działa lepiej w większych i bardziej złożonych przypadkach.

Istnieje trzecia technika zwana wspólnym kluczem podstawowym. Ta technika jest często stosowana w połączeniu z dziedziczeniem tabel klas. Specjalistyczne tabele dla podklas mają jako klucz podstawowy kopię klucza podstawowego odpowiedniego wpisu w tabeli samochodowej. Tę kolumnę identyfikatora można zadeklarować jako klucz podstawowy i klucz obcy.

Wymaga to trochę dodatkowego programowania przy dodawaniu nowych samochodów, ale sprawia, że ​​dołączanie jest proste, łatwe i szybkie.

Nadklasy i podklasy zdarzają się cały czas w prawdziwym świecie. Nie bój się Ale przetestuj swój początkowy projekt pod kątem wydajności. Jeśli Twoja pierwsza próba jest prosta i solidna, będziesz mógł ją ulepszyć, aby przyspieszyć.

Nie ma nic złego w tym, że w twoim modelu jest tyle podtypów bytów, ile potrzeba, aby odzwierciedlić rzeczywistość danych, które próbujesz modelować. Pytanie nie dotyczy tego, czy podtypy są złą praktyką. Problemem może być to, czy to dobry model ?

Na przykład, pod twoim przykładem, co robisz z czymś takim jak Audi A4 eTron - która jest hybrydą typu plug-in? Czy to „samochód elektryczny”, czy „samochód hybrydowy”?

Drugim pytaniem, które musisz sobie zadać, jest to, dlaczego w ogóle piszesz na maszynie? Ile różnych predykatów masz w swoich podtypach? Czy któryś z tych predykatów jest wspólny dla podtypów? Sytuacja może się skomplikować.

Podpisywanie nie jest używane w projekcie bazy danych do klasyfikacji. Klasyfikacji można dokonać za pomocą kodów, kluczy obcych do tabel kodów lub flag. Podtypowanie służy do modelowania odrębnych zestawów predykatów dla różnych rodzajów rzeczy będących przedmiotem zainteresowania. Jeśli używasz podtypów tylko do klasyfikacji, to zła praktyka.

Jeśli twoje podtypy w jasny i jednoznaczny sposób modelują różne zestawy predykatów dla rzeczy, o które dba twoja baza danych, jest to całkowicie dobra praktyka, bez względu na to, ile podtypów potrzebujesz.