Você está implementando o Entity-Attribute-Value antipadrão. Isso não pode ser um design de banco de dados normalizado, porque não é relacional.
O que eu sugiro é a Herança de tabela de classe padrão de design:
- Crie uma tabela para Organismos, contendo propriedades comuns a todas as espécies.
-
Crie uma tabela por espécie, contendo propriedades específicas para essa espécie. Cada uma dessas tabelas tem um relacionamento de 1 para 1 com Organisms, mas cada propriedade pertence à sua própria coluna.
____________________ ____________________ | 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) | |.... | |______________________|
Isso significa que você criará muitas tabelas, mas considere isso como uma compensação com os muitos benefícios práticos de armazenar propriedades de maneira relacionalmente correta:
- Você pode usar os tipos de dados SQL adequadamente, em vez de tratar tudo como um varchar de forma livre.
- Você pode usar restrições ou tabelas de pesquisa para restringir determinadas propriedades por um conjunto predefinido de valores.
- Você pode tornar as propriedades obrigatórias (ou seja, NOT NULL) ou usar outras restrições.
- Dados e índices são armazenados de forma mais eficiente.
- As consultas são mais fáceis de escrever e mais fáceis de executar pelo RDBMS.
Para saber mais sobre esse design, consulte o livro de Martin Fowler Patterns of Enterprise Application Architecture , ou minha apresentação Modelos práticos orientados a objetos em SQL , ou meu livro, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .
