Конструкция Таблицы Entity-Attribute-Value

в настоящее время я разрабатываю структуру базы данных для раздела продуктов платформы электронной коммерции. Он должен быть спроектирован таким образом, чтобы можно было продавать бесконечное количество различных видов продукции с бесконечным количеством различных атрибутов.

например. Атрибуты ноутбука будут ОЗУ, Размер экрана, вес и т. д. Атрибуты книги-автор, ISBN, издатель и т. д.

похоже, что структура EAV будет самой подходящий.

  • выберите продукт
  • продукт принадлежит к набору атрибута
  • набор атрибутов содержит атрибуты x и y
    • атрибут x - это тип данных datetime (значения, хранящиеся в attribute_values_datetime)
    • атрибут y-тип данных int (значения, хранящиеся в attribute_values_int)
  • каждое определение атрибута обозначает тип (i,e, x имеет тип столбца - > тип данных)

Если выше, Могу ли я присоединиться к выбору к таблице attribute_values_datetime, чтобы получить правильные данные без получения результирующего набора и создания второго запроса теперь, когда таблица известна? Будет ли большой хит производительности при построении запроса этого типа или ниже будет более подходящим (хотя и менее функциональным)

  • выберите продукт
  • продукт принадлежит к набору атрибута
  • набор атрибутов содержит атрибуты x и y
    • атрибут x тип данных datetime, но хранится как текст в attribute_values
    • атрибут y является типом данных int, но хранится как текст в attribute_values
24
database-design database-schema entity-attribute-value mysql sql

3 ответов

Я собираюсь предложить противоположное мнение по большинству комментариев по этому вопросу. В то время как ЕАВ-это зло по всем причинам, которые вы можете найти подробно объяснены много раз здесь на SO и DBA.SE и в других местах есть одно действительно распространенное приложение, для которого большинство вещей, которые неправильны с EAV, в значительной степени не имеют значения, и (немногие) преимущества EAV очень важны. Это приложение онлайн каталоги продуктов.

основная проблема с EAV что это не позволяет базе данных делать то, что она действительно хорошо делает, что помогает придать надлежащий контекст различным атрибутам информации о разных сущностях, расположив их в - схемы. Наличие схемы дает много преимуществ для доступа, интерпретации и обеспечения целостности ваших данных.

факт о каталогах продуктов заключается в том, что атрибуты продукта почти полностью не имеют значения в систему каталогов. Системы каталогов продуктов делают (самое большее) три вещи с атрибутами продукта.

  1. отображение атрибутов продукта в списке для конечных пользователей в виде: {имя атрибута}: {значение атрибута}.

  2. отображение атрибутов нескольких продуктов в сетке сравнения, где атрибуты разных продуктов выстраиваются друг против друга (продукты, как правило, столбцы, атрибуты, как правило, строки)

  3. правила езды для что-то (например, ценообразование) на основе определенных комбинаций атрибутов/значений.

Если все, что делает ваша система, - это отрыгивать информацию, семантически не относящуюся (к системе), то схема для этой информации в основном бесполезна. На самом деле схема встает на пути в онлайн-каталоге продуктов, особенно если в вашем каталоге много различных типов продуктов, потому что вам всегда нужно возвращаться в схему, чтобы возиться с ней, чтобы разрешить для новых категорий продуктов или типов атрибутов.

из-за того, как он используется, даже тип данных значения атрибута в каталоге продуктов не обязательно (жизненно) важен. Для некоторых атрибутов вы можете наложить противопоказания, например "должно быть число" или " должно исходить из этого списка {...}". Это зависит от того, насколько важна согласованность атрибутов для вашего каталога и насколько вы хотите, чтобы ваша реализация была сложной. Просмотр каталогов продуктов нескольких интернет-магазинов Я бы сказал, что большинство готовы обменять простоту на последовательность.

да, подслушивание-зло, за исключением тех случаев, когда это не так.

29

да, обычно существует большое наказание при сборке запросов для модели EAV. Есть большие штрафы за производительность для проверки самосогласованности данных, потому что СУБД не сможет сделать это за вас. Если что-то пойдет не так, СУБД не сможет вам сказать.

с более ортодоксальным дизайном базы данных, как рекомендовано Одед в комментариях СУБД гарантирует, что данные в базе данных более согласованы. Я бы настоятельно адвоката использование обычного (не-EAV) дизайна.

2

Я не знаю, должно ли это быть комментарием или ответом. Тем не менее, я иду.

Я не знаю точно, что вы строите. Но вы заглянули в структура базы данных Magento EAV? Да, это может быть медленно, запросы могут быть огромными, но для нас плюсы больше, чем минус. А с другой стороны, magento заботится о запросах.

мы находимся в середине миграции нашего интернет-магазина (магазин среднего размера), чтобы использовать Magento и сейчас мы очень довольны подходом EAV.

2