Sie implementieren den Entity-Attribute-Value Antimuster. Dies kann kein normalisiertes Datenbankdesign sein, da es nicht relational ist.
Was ich stattdessen vorschlagen würde, ist die Klassentabellenvererbung Entwurfsmuster:
- Erstellen Sie eine Tabelle für Organismen, die Eigenschaften enthält, die allen Arten gemeinsam sind.
-
Erstellen Sie eine Tabelle pro Art, die Eigenschaften enthält, die für diese Art spezifisch sind. Jede dieser Tabellen hat eine 1-zu-1-Beziehung zu Organismen, aber jede Eigenschaft gehört in eine eigene Spalte.
____________________ ____________________ | 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) | |.... | |______________________|
Das bedeutet zwar, dass Sie viele Tabellen erstellen werden, aber betrachten Sie dies als Kompromiss mit den vielen praktischen Vorteilen, Eigenschaften relational richtig zu speichern:
- Sie können SQL-Datentypen entsprechend verwenden, anstatt alles als Freiform-Varchar zu behandeln.
- Sie können Einschränkungen oder Nachschlagetabellen verwenden, um bestimmte Eigenschaften durch einen vordefinierten Satz von Werten einzuschränken.
- Sie können Eigenschaften obligatorisch machen (d. h. NICHT NULL) oder andere Einschränkungen verwenden.
- Daten und Indizes werden effizienter gespeichert.
- Abfragen sind für Sie einfacher zu schreiben und für das RDBMS einfacher auszuführen.
Weitere Informationen zu diesem Design finden Sie in Martin Fowlers Buch Patterns of Enterprise Application Architecture , oder meine Präsentation Praktische objektorientierte Modelle in SQL , oder mein Buch, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .
