Du implementerar Entity-Attribute-Value antimönster. Detta kan inte vara en normaliserad databasdesign, eftersom den inte är relationell.
Det jag skulle föreslå istället är Klassbordsarv designmönster:
- Skapa en tabell för organismer som innehåller egenskaper som är gemensamma för alla arter.
-
Skapa en tabell per art som innehåller egenskaper som är specifika för den arten. Var och en av dessa tabeller har en 1-till-1-relation med organismer, men varje egenskap hör hemma i sin egen kolumn.
____________________ ____________________ | 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) | |.... | |______________________|
Detta betyder att du kommer att skapa många tabeller, men se detta som en avvägning med de många praktiska fördelarna med att lagra egenskaper på ett relationellt korrekt sätt:
- Du kan använda SQL-datatyper på lämpligt sätt, istället för att behandla allt som varchar i fritt format.
- Du kan använda begränsningar eller uppslagstabeller för att begränsa vissa egenskaper med en fördefinierad uppsättning värden.
- Du kan göra egenskaper obligatoriska (dvs INTE NULL) eller använda andra begränsningar.
- Data och index lagras mer effektivt.
- Frågor är lättare för dig att skriva och lättare för RDBMS att köra.
För mer om denna design, se Martin Fowlers bok Patterns of Enterprise Application Architecture , eller min presentation Praktiska objektorienterade modeller i SQL , eller min bok, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .