Дизайн таблицы атрибутов-атрибутов

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

например. Атрибутами ноутбука были бы оперативная память, размер экрана, вес и т.д. Атрибутами книги были бы Author, ISBN, Publisher и т.д.

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

  • Выберите продукт
  • Продукт принадлежит атрибуту
  • Набор атрибутов содержит атрибуты x и y
    • Атрибут x - это тип данных datetime (значения, хранящиеся в атрибуте_values_datetime)
    • Атрибут y - это тип данных int (значения, хранящиеся в атрибуте_values_int)
  • Каждое определение атрибута обозначает тип (i, e, x имеет тип столбца → тип данных)

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

  • Выберите продукт
  • Продукт принадлежит атрибуту
  • Набор атрибутов содержит атрибуты x и y
    • Атрибут x - это тип данных datetime, но сохраненный как TEXT в атрибутах_значения
    • Атрибут y является типом данных int, но сохраняется как TEXT в атрибутах_значения

Ответы

Ответ 1

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

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

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

  • Отобразить атрибуты продукта в списке конечным пользователям в форме: {имя атрибута}: {значение атрибута}.

  • Отображение атрибутов нескольких продуктов в сетке сравнения, где атрибуты разных продуктов выстраиваются друг против друга (продуктами обычно являются столбцы, обычно атрибуты - строки)

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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