Ve skutečnosti se návrh, který jste popsal (společná tabulka plus tabulky specifické pro podtyp), nazývá Dědění tabulky tříd .
Dědičnost betonové tabulky všechny běžné atributy by byly duplikovány v tabulkách podtypů a neměli byste žádnou tabulku nadtypů jako nyní.
Jsem silně proti EAV. Považuji to za antivzor SQL. Může se to zdát jako elegantní řešení, protože vyžaduje méně stolů, ale později vás bude bolet hlava. Identifikovali jste několik nevýhod, ale existuje mnoho dalších. IMHO se EAV používá správně pouze v případě, že absolutně nesmíte vytvořte novou tabulku, když zavádíte nový podtyp, nebo pokud máte neomezený počet podtypů (např. uživatelé mohou definovat nové atributy ad hoc).
Máte mnoho podtypů, ale stále je jich konečný počet, takže kdybych dělal tento projekt, zůstal bych u Dědičnosti tabulky tříd . Můžete mít několik řádků každého podtypu, ale alespoň máte určitou jistotu, že všechny řádky v každém podtypu mají stejné sloupce, můžete použít NOT NULL pokud potřebujete, můžete použít datové typy SQL, můžete použít omezení referenční integrity atd. Z relačního hlediska je to lepší návrh než EAV.
Další možnost, kterou jste nezmínil, se nazývá Serializovaný LOB . To znamená, že přidejte sloupec BLOB pro semistrukturovanou kolekci vlastních atributů. Uložte si XML, YAML, JSON nebo svůj vlastní DSL v tom sloupci. Nebudete moci snadno analyzovat jednotlivé atributy z tohoto BLOB pomocí SQL, budete muset načíst celý BLOB zpět do aplikace a extrahovat jednotlivé atributy v kódu. Takže v některých ohledech je to méně pohodlné. Ale pokud to uspokojí vaše využití dat, pak na tom není nic špatného.