Я искал решение для базы данных, позволяющее определять поля и значения, определенные пользователем (разрешая неограниченное число). На первый взгляд EAV казался правильным, но после некоторого чтения я уже не уверен.
Каковы плюсы и минусы EAV?
Есть ли альтернативный метод базы данных, чтобы разрешить пользовательские атрибуты/поля и значения?
Это не следует рассматривать как исчерпывающий ответ, а всего лишь несколько пунктов по теме.
Так как вопрос также отмечен тегом [sql], скажем, что в общем случае > EAV. Вы все еще можете создать модель EAV в SQL, но вам придется пожертвовать многими преимуществами, которые даст реляционная база данных. Не только вы не сможете обеспечить ссылочную целостность, использовать типы данных SQL для значений и применять обязательные атрибуты, но даже самые простые запросы могут стать трудными для записи. Фактически, для преодоления этого ограничения несколько решений EAV полагаются на дублирование данных, вместо того, чтобы соединяться со связанными таблицами, что, как вы можете себе представить, имеет множество недостатков.
Если вам действительно нужен схематический дизайн, "позволяющий неограниченное количество атрибутов", лучше всего использовать NoSQL решение. Несмотря на то, что недостатки EAV по отношению к реляционным базам данных также применимы к альтернативам NoSQL, вам будут предложены дополнительные функции, которые трудно достичь с помощью обычных баз данных SQL. Например, обычно хранилища данных NoSQL можно масштабировать гораздо проще, чем реляционные базы данных, просто потому, что они были разработаны для решения какой-то проблемы масштабируемости, и они преднамеренно отказались от функций, которые затрудняют масштабирование.
Многие облачные вычислительные платформы (например, предлагаемые Amazon, Google и Microsoft) представлены хранилища данных на основе модели EAV, где может быть связано произвольное количество атрибутов с данным объектом. Если вы планируете внедрить свое приложение в облако, вы можете рассматривать это как как преимущество для бизнеса, так и техническое, потому что сильная конкуренция между крупными поставщиками приводит к тому, что соотношение цены и качества на очень высоких уровнях, постоянно наращивая функции и снижая финансовые затраты и затраты на внедрение.
Посмотрите на posgtres hstore http://www.postgresql.org/docs/9.0/static/hstore.html это будет делать именно то, что вы хотите, без большинства недостатков.
Есть ли альтернативный метод базы данных, чтобы разрешить пользовательские атрибуты/поля и значения?
Один из вариантов заключается в изменении схемы базы данных на основе пользовательского ввода: например, когда пользователь хочет новое поле, затем добавьте соответствующий столбец в базу данных.