En realidad, el diseño que describió (tabla común más tablas específicas de subtipos) se llama Class Table Inheritance .
Herencia de tablas concretas tendría todos los atributos comunes duplicados en las tablas de subtipos, y no tendría una tabla de supertipos como la tiene ahora.
Estoy fuertemente en contra de EAV. Lo considero un antipatrón SQL. Puede parecer una solución elegante porque requiere menos mesas, pero te estás preparando para muchos dolores de cabeza más adelante. Usted identificó un par de desventajas, pero hay muchas otras. En mi humilde opinión, EAV se usa apropiadamente solo si absolutamente no debe cree una nueva tabla cuando introduzca un nuevo subtipo, o si tiene un número ilimitado de subtipos (por ejemplo, los usuarios pueden definir nuevos atributos ad hoc).
Tiene muchos subtipos, pero sigue siendo un número finito de ellos, así que si estuviera haciendo este proyecto me quedaría con Herencia de tabla de clase . Puede tener pocas filas de cada subtipo, pero al menos tiene cierta seguridad de que todas las filas de cada subtipo tienen las mismas columnas, puede usar NOT NULL si lo necesita, puede usar tipos de datos SQL, puede usar restricciones de integridad referencial, etc. Desde una perspectiva relacional, es un mejor diseño que EAV.
Una opción más que no mencionaste se llama LOB serializado . Es decir, agregue una columna BLOB para una colección semiestructurada de atributos personalizados. Almacene XML, YAML, JSON o su propio DSL en esa columna. No podrá analizar atributos individuales de ese BLOB fácilmente con SQL, tendrá que recuperar todo el BLOB en su aplicación y extraer atributos individuales en el código. Entonces, de alguna manera, es menos conveniente. Pero si eso satisface su uso de los datos, entonces no hay nada de malo en ello.
