Это не должно считаться исчерпывающим ответом, это всего лишь несколько моментов по теме.
Поскольку вопрос также помечен тегом [sql], позвольте мне сказать, что, как правило, реляционные базы данных не особенно подходят для хранения данных с использованием модели EAV . , Вы все еще можете разработать модель EAV на SQL, но вам придется пожертвовать многими преимуществами, которые дает реляционная база данных. Мало того, что вы не сможете обеспечить ссылочную целостность, использовать типы данных SQL для значений и принудительные обязательные атрибуты, но даже самые простые запросы могут стать трудными для написания. Фактически, чтобы преодолеть это ограничение, некоторые решения EAV полагаются на дублирование данных, а не на объединение со связанными таблицами, которые, как вы можете себе представить, имеют множество недостатков.
Если вам действительно нужен дизайн без схемы, «допускающий неограниченное количество атрибутов», то вам лучше всего использовать решение NoSQL . Даже несмотря на то, что недостатки EAV по отношению к реляционным базам данных также применимы к альтернативам NoSQL, вам будут предложены дополнительные функции, которые трудно реализовать с помощью традиционных баз данных SQL. Например, обычно хранилища данных NoSQL можно масштабировать гораздо проще, чем реляционные базы данных, просто потому, что они были разработаны для решения какой-то проблемы масштабируемости, и они намеренно отбрасывали функции, затрудняющие масштабирование.
На многих платформах облачных вычислений (например, предлагаемых Amazon , Google и Microsoft ) хранилища данных основаны на модели EAV, где произвольное число атрибутов могут быть связаны с данным объектом. Если вы рассматриваете возможность развертывания своего приложения в облаке, вы можете рассматривать это как деловое преимущество, так и техническое, потому что сильная конкуренция между крупными поставщиками приводит к очень высокому соотношению цены и стоимости, постоянно повышая функциональность и снижая финансовые затраты и затраты на внедрение.