Egentligen kallas designen du beskrev (gemensam tabell plus undertypspecifika tabeller) Klasstabellsarv a> .
Arv av betongbord skulle ha alla vanliga attribut duplicerade i undertypstabellerna, och du skulle inte ha någon supertyptabell som du gör nu.
Jag är starkt emot EAV. Jag anser att det är ett SQL-antimönster. Det kan tyckas vara en elegant lösning eftersom det kräver färre bord, men du ställer dig inför mycket huvudvärk senare. Du identifierade ett par av nackdelarna, men det finns många andra. IMHO, EAV används endast på lämpligt sätt om du absolut inte får skapa en ny tabell när du introducerar en ny undertyp, eller om du har ett obegränsat antal undertyper (t.ex. användare kan definiera nya attribut ad hoc).
Du har många undertyper, men fortfarande ett ändligt antal av dem, så om jag gjorde det här projektet skulle jag hålla mig till Klasstabellsarv . Du kan ha några rader av varje undertyp, men du kan åtminstone vara säker på att alla rader i varje undertyp har samma kolumner, du kan använda NOT NULL om du behöver kan du använda SQL-datatyper, du kan använda referensintegritetsbegränsningar, etc. Ur ett relationsperspektiv är det en bättre design än EAV.
Ytterligare ett alternativ som du inte nämnde heter Serialized LOB . Det vill säga, lägg till en BLOB-kolumn för en semistrukturerad samling av anpassade attribut. Lagra XML, YAML, JSON eller din egen DSL i den kolumnen. Du kommer inte att kunna analysera individuella attribut från den BLOB enkelt med SQL, du måste hämta hela BLOB tillbaka till din applikation och extrahera individuella attribut i kod. Så på något sätt är det mindre bekvämt. Men om det tillfredsställer din användning av data, så är det inget fel med det.