Faktisk kaldes det design, du beskrev (fælles tabel plus undertype-specifikke tabeller) Klassetabelarv a> .
Betonbordsarv ville have alle de almindelige attributter duplikeret i undertypetabellerne, og du ville ikke have nogen supertypetabel, som du har nu.
Jeg er stærkt imod EAV. Jeg betragter det som et SQL-antimønster. Det kan virke som en elegant løsning, fordi det kræver færre borde, men du sætter dig selv op til en masse hovedpine senere. Du identificerede et par af ulemperne, men der er mange andre. IMHO, EAV bruges kun korrekt, hvis du absolut ikke må opret en ny tabel, når du introducerer en ny undertype, eller hvis du har et ubegrænset antal undertyper (brugere kan f.eks. definere nye attributter ad hoc).
Du har mange undertyper, men stadig et begrænset antal af dem, så hvis jeg lavede dette projekt, ville jeg holde mig til Klassebordsarv . Du kan have få rækker af hver undertype, men du har i det mindste en vis sikkerhed for, at alle rækker i hver undertype har de samme kolonner, du kan bruge NOT NULL hvis du har brug for det, kan du bruge SQL-datatyper, du kan bruge referenceintegritetsbegrænsninger osv. Fra et relationelt perspektiv er det et bedre design end EAV.
En anden mulighed, som du ikke nævnte, hedder Serialiseret LOB . Det vil sige, tilføj en BLOB-kolonne for en semistruktureret samling af brugerdefinerede attributter. Gem XML, YAML, JSON eller din egen DSL i den kolonne. Du vil ikke være i stand til nemt at parse individuelle attributter ud af den BLOB med SQL, du bliver nødt til at hente hele BLOB tilbage i din applikation og udtrække individuelle attributter i kode. Så på nogle måder er det mindre bekvemt. Men hvis det tilfredsstiller din brug af dataene, så er der ikke noget galt med det.