Защо? Направете всичко вашите обекти изискват да бъдат разширяеми по този начин? Вероятно не - в повечето приложения има най-много един или два обекта, които биха се възползвали от това ниво на гъвкавост. Другите субекти всъщност се възползват от стабилността и яснотата на не променящ се през цялото време.
EAV е пример за Ефектът на вътрешната платформа :
С други думи, сега е ваша отговорност да напишете код на приложението, за да правите всички неща, които правилната RDBMS вече предоставя, като ограничения и типове данни. Дори нещо толкова просто като да направите колона задължителна като NOT NULL не работи в EAV.
Вярно е, че понякога проектът изисква много таблици. Но вие се заблуждавате, ако смятате, че сте опростили проекта, като сте направили само две таблици. Все още ще имате точно толкова отделни обекти, колкото бихте имали таблици, но сега от вас зависи да ги предпазите от превръщането им в купчина боклук.
Преди да инвестирате твърде много време в EAV, прочетете тази история за компания, която почти спря да функционира, защото някой се опита да направи своето хранилище на данни произволно гъвкаво:Bad CaRMa .
Освен това написах повече за EAV в публикация в блог, EAV FAIL , и в една глава от моята книга, SQL Antipatterns:Избягване на клопките на програмирането на бази данни .
