Wdrażasz Entity-Attribute-Value antywzór. To nie może być znormalizowany projekt bazy danych, ponieważ nie jest relacyjny.
Zamiast tego sugerowałbym Dziedziczenie tabeli klas wzór projektu:
- Utwórz jedną tabelę dla organizmów, zawierającą właściwości wspólne dla wszystkich gatunków.
-
Utwórz jedną tabelę dla każdego gatunku, zawierającą właściwości specyficzne dla tego gatunku. Każda z tych tabel ma relację 1 do 1 z organizmami, ale każda właściwość należy do własnej kolumny.
____________________ ____________________ | 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) | |.... | |______________________|
Oznacza to, że utworzysz wiele tabel, ale potraktuj to jako kompromis z wieloma praktycznymi korzyściami związanymi z przechowywaniem właściwości w sposób poprawny relacyjnie:
- Możesz odpowiednio używać typów danych SQL, zamiast traktować wszystko jako varchar o dowolnej formie.
- Możesz użyć ograniczeń lub tabel przeglądowych, aby ograniczyć niektóre właściwości za pomocą predefiniowanego zestawu wartości.
- Możesz uczynić właściwości obowiązkowymi (tj. NOT NULL) lub użyć innych ograniczeń.
- Dane i indeksy są przechowywane wydajniej.
- Zapytania są łatwiejsze do pisania i łatwiejsze do wykonania przez RDBMS.
Więcej informacji na temat tego projektu można znaleźć w książce Martina Fowlera Wzorce architektury aplikacji korporacyjnych lub moja prezentacja Praktyczne modele obiektowe w SQL lub moja książka Antywzorce SQL:unikanie pułapek programowania baz danych .
