Stai implementando il Entity-Attribute-Value antimodello. Questo non può essere un progetto di database normalizzato, perché non è relazionale.
Quello che suggerirei invece è l'Ereditarietà tabella classi modello di progettazione:
- Crea una tabella per Organismi, contenente proprietà comuni a tutte le specie.
-
Crea una tabella per specie, contenente le proprietà specifiche di quella specie. Ognuna di queste tabelle ha una relazione 1 a 1 con Organismi, ma ogni proprietà appartiene a una propria colonna.
____________________ ____________________ | 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) | |.... | |______________________|
Ciò significa che creerai molte tabelle, ma consideralo come un compromesso con i numerosi vantaggi pratici dell'archiviazione delle proprietà in modo relazionalmente corretto:
- Puoi usare i tipi di dati SQL in modo appropriato, invece di trattare tutto come un varchar in formato libero.
- Puoi utilizzare vincoli o tabelle di ricerca per limitare determinate proprietà in base a un insieme predefinito di valori.
- Puoi rendere le proprietà obbligatorie (cioè NOT NULL) o utilizzare altri vincoli.
- I dati e gli indici vengono archiviati in modo più efficiente.
- Le query sono più facili da scrivere e da eseguire per RDBMS.
Per ulteriori informazioni su questo progetto, vedere il libro di Martin Fowler Patterns of Enterprise Application Architecture o la mia presentazione Modelli pratici orientati agli oggetti in SQL , o il mio libro, SQL Antipatterns:evitare le insidie della programmazione di database .
