Antipattern?
В общия случай втората таблица е сантишаблона в контекста на дизайна на база данни. И още повече, има конкретно име:Entity-Attribute-Value (EAV). Има някои случаи, когато използването на този дизайн е оправдано, но това са редки случаи - и дори там може да се избегне.
Защо EAV е лош
Поддръжка за целостта на данните
Въпреки факта, че подобна структура изглежда по-„гъвкава“ или „напреднала“, този дизайн има слабост.
- Невъзможно е да се направят задължителни атрибути . Не можете да направите някои атрибути задължителни, тъй като атрибутът вече се съхранява като ред - и единственият знак, че атрибутът не е зададен - е, че съответният ред отсъства в таблицата. SQL няма да ви позволи да изградите такова ограничение изначално - по този начин ще трябва да проверите това в приложението - и, да, запитвайте вашата таблица всеки път
- Смесване на типове данни . Няма да можете да използвате стандартни SQL типове данни. Тъй като колоната за стойности трябва да бъде "супер-тип" за всички съхранени стойности в нея. Това означава - като цяло ще трябва да съхранявате всички данни като необработени низове . Тогава ще видите колко болезнено е да работите с дати като низове, прехвърлянето на типове данни всеки път, проверката на целостта на данните и т.н.
- Невъзможно е да се наложи референтна неприкосновеност . В нормална ситуация можете да използвате външен ключ, за да ограничите стойностите си с тези, които са дефинирани в родителската таблица. Но не в този случай - това е, защото референтната цялост се прилага към всеки ред в таблицата, но не и за стойностите на редовете. Така че - ще загубите това предимство - и то е едно от основните във връзка DB
- Невъзможно е задаване на имена на атрибути . Това означава - не можете правилно да ограничите името на атрибута на ниво DB. Например, ще напишете
"customer_name"като име на атрибут в първия случай - и друг разработчик ще забрави това и ще използва"name_of_customer". И... всичко е наред, DB ще предаде това и ще приключите с часове, прекарани в отстраняване на грешки в този случай.
Реконструкция на ред
Освен това реконструкцията на редове ще бъде ужасна в общия случай. Ако имате например 5 атрибута - това ще бъдат 5 самостоятелни JOIN -с. Жалко за такъв прост - на пръв поглед - случай. Така че не искам дори да си представям как ще поддържате 20 атрибута.
Може ли да бъде оправдано?
Моята точка е - не. В RDBMS винаги ще има начин да се избегне това. Ужасно е. И ако EAV е предназначен да се използва, тогава най-добрият избор може да бъде нерелационен бази данни.
