Вие внедрявате Entity-Attribute-Value антишаблон. Това не може да бъде нормализиран дизайн на база данни, защото не е релационен.
Това, което бих предложил вместо това, е Наследяване на класова таблица шаблон за проектиране:
- Създайте една таблица за организми, съдържаща свойства, общи за всички видове.
-
Създайте по една таблица за всеки вид, съдържаща свойства, специфични за този вид. Всяка от тези таблици има връзка 1 към 1 с организми, но всяко свойство принадлежи към собствена колона.
____________________ ____________________ | 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) | |.... | |______________________|
Това означава, че ще създадете много таблици, но смятайте това за компромис с многото практически ползи за съхраняване на свойства по релационно правилен начин:
- Можете да използвате SQL типове данни по подходящ начин, вместо да третирате всичко като varchar в свободна форма.
- Можете да използвате ограничения или справочни таблици, за да ограничите определени свойства чрез предварително зададен набор от стойности.
- Можете да направите свойствата задължителни (т.е. NOT NULL) или да използвате други ограничения.
- Данните и индексите се съхраняват по-ефективно.
- Заявките са по-лесни за писане и по-лесни за RDBMS за изпълнение.
За повече информация относно този дизайн вижте книгата на Мартин Фаулър Модели на архитектурата на корпоративните приложения , или моята презентация Практически обектно-ориентирани модели в SQL , или моята книга, SQL Antipatterns:Избягване на капаните на програмирането на бази данни .
