Vous implémentez le Entity-Attribute-Value anti-modèle. Il ne peut s'agir d'une conception de base de données normalisée, car elle n'est pas relationnelle.
Ce que je suggérerais à la place est le Class Table Inheritance.html">Class Table Inheritance modèle de conception :
- Créez un tableau pour les organismes, contenant les propriétés communes à toutes les espèces.
-
Créez un tableau par espèce, contenant les propriétés spécifiques à cette espèce. Chacune de ces tables a une relation 1 à 1 avec les organismes, mais chaque propriété appartient à sa propre colonne.
____________________ ____________________ | 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) | |.... | |______________________|
Cela signifie que vous allez créer de nombreuses tables, mais considérez cela comme un compromis avec les nombreux avantages pratiques du stockage des propriétés d'une manière relationnellement correcte :
- Vous pouvez utiliser les types de données SQL de manière appropriée, au lieu de tout traiter comme un varchar de forme libre.
- Vous pouvez utiliser des contraintes ou des tables de recherche pour restreindre certaines propriétés par un ensemble prédéfini de valeurs.
- Vous pouvez rendre les propriétés obligatoires (c'est-à-dire NOT NULL) ou utiliser d'autres contraintes.
- Les données et les index sont stockés plus efficacement.
- Les requêtes sont plus faciles à écrire pour vous et plus faciles à exécuter pour le SGBDR.
Pour en savoir plus sur cette conception, consultez le livre de Martin Fowler Patterns of Enterprise Application Architecture , ou ma présentation Modèles pratiques orientés objet en SQL , ou mon livre, Antipatterns SQL :éviter les pièges de la programmation de bases de données .
