Альтернатива EAV, структура базы?

Добрый день!


В интернет-магазине встает вопрос о дополнительных параметрах товаров. Параметров конечное число. Много типов товаров. Первое что приходит в голову — примерная архитектура EAV. В интернетах пишут что это плохо и альтернатива — для каждого типа товара создавать свою таблицу в базе.


Хотелось бы знать, чем же все таки это плохо. Реальные причины, а не вымышленные что «не тру». И посмотреть структуру базы, как с ней работать если сделать для каждого типа товара свою таблицу. Как показать например все товары в наличии. Или все товары красного цвета. Если есть несколько таблиц для каждого типа товара… Не могу придумать оптимальную схему.


Используется ms sql 2008.


И еще… Я изначально знаю все возможные параметры, т.е. будет 2 таблицы… Products и ProductsDescriptors в которой записано ProductID(int), DescriptorID(int), DescriptorValue(str). И знаю какой ID что подразумевает на этапе создания. Т.е. это не интернет-магазин для абстрактных товаров, а товары я знаю. Например DescriptorID=7 отвечает за цвет телевизора…
  • Вопрос задан
  • 17128 просмотров
Пригласить эксперта
Ответы на вопрос 3
alekciy
@alekciy
Вёбных дел мастер
Структура базы. На тестах 250 тыс. товаров с 10 тыс. параметров (10 параметров на один товар) отрабатывает менее чем за 1 мс на posgresql, так что самым тормозным местом будет явно не база.

>Хотелось бы знать, чем же все таки это плохо.
Ни чего плохого в EAV нет. Если под текущий размер базы выделены достаточные аппаратные ресурсы и в базе в нормальном виде расставлены индексы, то самым тормозным местом будет явно не база. Так что «советчиков» которые без конкретных аргументов так говорят можно сразу спокойно слать лесом.
Ответ написан
@vladar
Вообще, лучшая альтернатива EAV — schemaless-базы, тот же MongoDB, например. Другой вариант — использовать SQL (EAV или отдельные таблицы) + schemaless поисковик (например, elasticsearch).
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Обычно для интернет-магазинов EAV структура приблизительно следующая:
Категория (* — *) Опция ( 1 — *) Значение ( * — 1 ) Продукт
Поиск товаров допустим реализуется через INNER JOIN и создает довольно большие накладные расходы. Это единственный, и довольно существенный минус этого подхода. Решается он использованием вьюх в базе данных, или же NoSQL решений. Так же есть варианты использовать фасеточный поиск, например через Sphinx. Но гибкость разработки как по мне довольно большой плюс.

В вашем случае, если реализовать ваш вариант с таблицей дескриптеров, получается такая структура:
Товар (* — *) Значение ( 1 — * ) Дескриптер.
Причем, если значения дескриптеров вам известны, то логично вынести это скажем в ENUM или еще как. По сути это не есть паттрен EAV, это просто одна из тех самых альтернатив.

Поиск по такой структуре так же будет реализован через INNER JOIN (хотя можно и по другому, но по идее все упирается только в индексы, и от способа поиска производительность не сильно будет различаться) и все равно будет медленнее нежели через вью или просто из таблицы.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы