Está implementando el Entity-Attribute-Value antipatrón. Este no puede ser un diseño de base de datos normalizado, porque no es relacional.
Lo que sugeriría en cambio es la Herencia de tabla de clase patrón de diseño:
- Cree una tabla para Organismos, que contenga propiedades comunes a todas las especies.
-
Cree una tabla por especie, que contenga propiedades específicas de esa especie. Cada una de estas tablas tiene una relación de 1 a 1 con Organismos, pero cada propiedad pertenece a su propia columna.
____________________ ____________________ | Organisms | | Species | |--------------------| |--------------------| |OrganismId (int, PK)| |SpeciesId (int, PK) | |SpeciesId (int, FK) |∞---------1|Name (varchar) | |Name (varchar) | |____________________| |____________________| 1 | | 1 ______________________ | HumanOrganism | |----------------------| |OrganismId (int, FK) | |Sex (enum) | |Race (int, FK) | |EyeColor (int, FK) | |.... | |______________________|
Esto significa que creará muchas tablas, pero considere esto como una compensación con los muchos beneficios prácticos de almacenar propiedades de una manera relacionalmente correcta:
- Puede usar los tipos de datos SQL de manera adecuada, en lugar de tratar todo como un varchar de formato libre.
- Puede usar restricciones o tablas de búsqueda para restringir ciertas propiedades mediante un conjunto predefinido de valores.
- Puede hacer que las propiedades sean obligatorias (es decir, NOT NULL) o usar otras restricciones.
- Los datos y los índices se almacenan de manera más eficiente.
- Las consultas son más fáciles de escribir para usted y más fáciles de ejecutar para el RDBMS.
Para obtener más información sobre este diseño, consulte el libro de Martin Fowler Patterns of Enterprise Application Architecture , o mi presentación Modelos prácticos orientados a objetos en SQL , o mi libro, Antipatrones SQL:Cómo evitar las trampas de la programación de bases de datos .
