Имеет ли смысл разбивать значения свойств товаров по разным таблицам?

Question

[Максим Зайцев]

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

Comments

[Евгений Ромашкан]

Запись и чтение в jsonb быстрее чем EAV

Answer 1

[unfilled]

EAV (entity-attribute-value) и быстродействие - это, в общем случае, понятия прямо противоположные. Например, вы захотите сделать выбор всех товаров со свойством "Вес" и значением свойства 500 грамм - никакие индексы вам не помогут (точнее мало помогут), при достаточно большом количестве товаров и свойств.
В обоих случаях (всё в одной EAV-таблице, всё в EAV-таблицах по типам данных) у вас возможен мусор в базе, т.к. не будут работать никакие ограничения целостности (FK, CHECK, DEFAULT).
Если вы всё-таки хотите работать с EAV, можно сделать таблицу Entity|Attribute|Value_str|Value_int|Value_boolean. Какой, кхм, сорт выбирать - имхо, разницы нет.

Comments

[Максим Зайцев]

Честно говоря предложенное вами решение касательно

сделать таблицу Entity|Attribute|Value_str|Value_int|Value_boolean

выглядит уж очень странным.

Вы говорите что подход EAV не очень, есть предложения какой подход использовать вместо него?

[unfilled]

Максим Зайцев, имхо, любой EAV - "странный":). Этот вариант ничуть не лучше и не хуже любого другого EAV. В нём будет меньше соединений с таблицами свойств, чем в варианте с разными таблицами, но нужно будет реализовывать больше логики при определении этих свойств.
Для решения такой проблемы (разные свойства разных сущностей), в РСУБД, мне известно 3 шаблона проектирования (правда не помню как они называются корректно):
1. Все свойства в одной таблице, каждому свойству свой столбец. Если не применимо к данному продукту - NULL.
2. Продукты делятся на "категории с общими свойствами":
2.1 Для каждой категории вводится собственная таблица со всеми свойствами - каждому свойству свой столбец, NULL'ов нет
2.2 Выделяются общие свойства, которые есть у всех продуктов - они лежат в одной таблице, каждой категории заводится отдельная таблица, которая хранит свойства уникальные именно для этой категории.

Четвёртый вариант - это EAV. Пятый - хранить свойства в чём-то типа XML или JSON (этот вариант мне не нравится совершенно).

Я обычно использую 2.2, но у меня можно выделить конечное количество категорий (до 10, обычно).
Если у вас категорий очень много, то возможно EAV и выход, но проблемы с мусором и быстродействием на больших объёмах (когда всё перестанет влезать в память) практически гарантированы (если будет поиск по значениям свойств).

UPD. А, во, нашёл

[Максим Зайцев]

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

Можно поподробнее Пров арканит 2.2, заинтересовал такой подход, выглядит вполне дееспособным, но хочется уточнить про категории, в идеале с примерами для лучшего пониманиям.

[unfilled]

Максим Зайцев, это я так Class Table Inheritance "адаптировал". Вообще, речь именно про вынос конкретных наборов характеристик в отдельные таблицы.
Вариант со свойствами "для поиска", "прочих" и т.д. всё равно сведётся или к таблице с кучей столбцов, или к EAV, т.к. у разных продуктов будут непересекающиеся наборы характеристик.

[Максим Зайцев]

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

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

Answer 2

[Артем Черепахин]

Все очень опционально.
Если у вы данные в приложение передаете в json, то и храните в json(например, в постгресе хорошая поддержка таких типов полей)
, ключи, как первичные, так и внешние, вынесите в атрибуты таблицы. Этот подход даст большую гибкость в изменении свойств товаров. Я бы начал с него.
Упомянутый unfilled EAV, например, также даст вам возможность гибко менять/добавлять и удалять свойства товаров на странце. Но для получения результирующего набора данных нужно делать много соединений таблиц. А стоимость запроса зависит от многих факторов(наличие\отсутсвии индекса, объем выбираемых данных, соотношение объема к общему объему таблицы, ...) и от вашего скила.
Не бывает хороших или плохих структур\архитектур,а есть только структуры\архитектуры, которые отвечают или не отвечают текущим требованиям. Все очень сильно зависят от реализации и требований. Тут главное не попасть в "ошибку преждевременной оптимизации".
Любой из подходов чреват гемороями и деградации производительности. Тем более приложение будет меняться со временем.
Любая структура БД покажет себя только в реальных условия и на реальных данных и в нагрузке.

Comments

[Максим Зайцев]

Задача проста до нельзя. Спроектировать БД под большой интернет магазин с возможностью наращивать свойства и товары. Товары совершенно разные. Нужно быстро отображать данные по товарам и организовать быструю фильтрацию торов через поиск по фильтрам.

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

В своем прототипе я использовал именно EAV с разбиением значений по таблицам с разными типами. Спроектировать запросы было сложно, пришлось писать довольно сложный алгоритм который на лету понимал что от него требуется и генерировал SQL запрос максимально оптимизировавшийся его. В целом поиск по 40к тестовым товарам и где-то по 300 свойствам работает шустро, но я планирую что товаров должно быть около 200к и около 2к свойств

[Артем Черепахин]

В общем, смысл разбить есть:
-для правильности и нормальной формы
-OLAP-куб(нужна снежинка)
Опять же повторю, не обращая внимание на многие "ЕСЛИ" читать проще и быстрее с одной таблицы.