Het ontwerp dat u beschreef (algemene tabel plus subtype-specifieke tabellen) heet Class Table Inheritance .
Overerving van betonnen tafel zou alle gemeenschappelijke attributen gedupliceerd hebben in de subtypetabellen, en je zou geen supertypetabel hebben zoals nu.
Ik ben sterk tegen EAV. Ik beschouw het als een SQL-antipatroon. Het lijkt misschien een elegante oplossing omdat er minder tafels voor nodig zijn, maar je bezorgt jezelf later veel hoofdpijn. Je hebt een aantal nadelen geïdentificeerd, maar er zijn er nog veel meer. IMHO, EAV wordt alleen op de juiste manier gebruikt als u absoluut niet maak een nieuwe tabel wanneer u een nieuw subtype introduceert, of als u een onbeperkt aantal subtypes heeft (gebruikers kunnen bijvoorbeeld ad hoc nieuwe attributen definiëren).
Je hebt veel subtypen, maar nog steeds een eindig aantal, dus als ik dit project zou doen, zou ik het houden bij Class Table Inheritance . Je hebt misschien een paar rijen van elk subtype, maar je hebt tenminste enige zekerheid dat alle rijen in elk subtype dezelfde kolommen hebben, je kunt NOT NULL gebruiken als dat nodig is, kunt u SQL-gegevenstypen gebruiken, kunt u referentiële integriteitsbeperkingen gebruiken, enz. Vanuit een relationeel perspectief is het een beter ontwerp dan EAV.
Een andere optie die je niet noemde, is Geserialiseerde LOB . Dat wil zeggen, voeg een BLOB-kolom toe voor een semi-gestructureerde verzameling aangepaste kenmerken. Sla XML, YAML, JSON of uw eigen DSL op in die kolom. Je zult individuele attributen niet gemakkelijk uit die BLOB kunnen ontleden met SQL, je zult de hele BLOB terug moeten halen in je applicatie en individuele attributen in code moeten extraheren. Dus in sommige opzichten is het minder handig. Maar als dat voldoet aan uw gebruik van de gegevens, dan is daar niets mis mee.