W rzeczywistości opisany przez Ciebie projekt (tabela wspólna oraz tabele specyficzne dla podtypów) nazywa się Dziedziczenie tabeli klas .
Dziedziczenie stołu betonowego miałby wszystkie wspólne atrybuty zduplikowane w tabelach podtypów i nie miałbyś żadnej tabeli nadtypów, tak jak teraz.
Jestem zdecydowanie przeciwny EAV. Uważam to za antywzorzec SQL. Może wydawać się to eleganckim rozwiązaniem, ponieważ wymaga mniejszej liczby stolików, ale później narażasz się na duży ból głowy. Zidentyfikowałeś kilka wad, ale jest wiele innych. IMHO, EAV jest używane właściwie tylko wtedy, gdy absolutnie nie wolno utwórz nową tabelę, gdy wprowadzasz nowy podtyp lub jeśli masz nieograniczoną liczbę podtypów (np. użytkownicy mogą definiować nowe atrybuty ad hoc).
Masz wiele podtypów, ale wciąż jest ich skończona liczba, więc gdybym robił ten projekt, trzymałbym się dziedziczenia tabeli klas . Możesz mieć kilka wierszy każdego podtypu, ale przynajmniej masz pewność, że wszystkie wiersze w każdym podtypie mają te same kolumny, możesz użyć NOT NULL jeśli potrzebujesz, możesz użyć typów danych SQL, możesz użyć ograniczeń integralności referencyjnej itp. Z perspektywy relacyjnej jest to lepszy projekt niż EAV.
Jeszcze jedna opcja, o której nie wspomniałeś, nazywa się Serializowany obiekt LOB . Oznacza to, że dodaj kolumnę BLOB dla częściowo ustrukturyzowanej kolekcji atrybutów niestandardowych. Przechowuj XML, YAML, JSON lub swój własny DSL w tej kolumnie. Nie będziesz w stanie łatwo przeanalizować poszczególnych atrybutów z tego BLOB za pomocą SQL, będziesz musiał pobrać cały BLOB z powrotem do swojej aplikacji i wyodrębnić poszczególne atrybuty w kodzie. Więc pod pewnymi względami jest to mniej wygodne. Ale jeśli to zadowala Twoje wykorzystanie danych, nie ma w tym nic złego.
