Макар и минималистична, както е показано, таблицата с атрибути на Model2 въвежда концепцията за мета-данни в микса, с всичко добро, което идва от него. Има и други предимства на Model2, например повишаването на производителността свързано с по-малък размер на редове (от таблицата със стойности), но бих искал да се съсредоточа върху концепцията за метаданни.
Дори както е Таблицата с атрибути на Model2 представлява хранилище на всички валидни атрибути (с model1 ще трябва да изпълните своеобразна обобщена заявка, за да получите такъв списък). Също така и както е , хранилището е достатъчно, за да въведе ограничения за външни ключове за да подпомогне поддържането на целостта на набора от данни (с модел 1 ще са необходими външни форми на валидиране на стойностите, съхранени в колоната с атрибути.
С няколко прости допълнения, таблицата с атрибути може да се превърне в универсално хранилище, което може да се използва за различни цели. Например таблицата може да включва някои от следните
- информация, като например удобно за показване име на всеки атрибут
- някои флагове, указващи типа на полето (числова спрямо низ срещу дата и т.н.), за диференцирана обработка/обработка
- конкретната таблица със стойности, където се съхранява основният атрибут (моделът показва само една таблица, но оптимизацията/мащабирането понякога изисква разделяне на таблиците)
- фактът, че атрибутът може да се съхранява като собствена колона в таблицата „Стойност“ (отново форма на оптимизация, по същество извличаща най-доброто от двата свята:гъвкавостта на схемата на модела EAV, но производителността на традиционните релационен модел за атрибутите, които са най-използваните и/или най-често срещаните за всички обекти.
- възможността за преименуване на атрибути, без да се нарушава основната таблица. Промени само на ниво метаданни.
- различна семантика, ориентирана към приложението. Например индикатори, че даден атрибут трябва да се предлага като едно от основните полета за търсене спрямо разширените.
Накратко, таблицата с атрибути се превръща в ресурс, който позволява на приложението да бъде наистина управлявано от данни (или по-точно, мета управлявани от данни). Всъщност може да ви хареса и таблица с обекти, т.е. такава, в която са събрани метаданните, отнасящи се до различните типове обекти:кои са различните типове обекти, кои атрибути са разрешени за кой тип обект и т.н.
Сега... обърнете внимание на коментара от zerkms , под самия въпрос. Въпреки всичките си предимства, моделът EAV идва и със своя дял от недостатъци и предизвикателства, както намекна сложността на заявките, които идват на ум, както и проблеми с производителността. Тези опасения обаче не трябва да дисквалифицират априори EAV:има много случаи на употреба, при които EAV е по-добър подход.
Ако приемем, че EAV е изборът от Model2, или дори нещо малко по-сложно е определено по-добро от model1.
