Интернет-магазин. Как хранить разновидности товаров в БД?

Question

[Hint]

Проектирую БД для интернет-магазина. Есть необходимость хранить информацию о похожих товара. Например, упаковка может быть 100, 200 или 500 грамм. Вкус может быть шоколадным или клубничным. Соответственно описания будет идентичными, а цены и кол-во на складе разными. В каталоге товар должен быть представлен одной позицией с набором опций. Как правильно хранить все это в БД?

Comments

[Urvin]

Реляционная БД?

[Hint]

Да, MySQL

[EugeneOZ]

Почему такой уверенный ответ? Почему не рассматриваете PostgreSQL или NoSQL варианты?

[Сергей Полозов]

Чем отличается PostgreSQL от MySQL на уровне проектирования...???

Answer 1

[raskumandrin]

Свойства вынести в отдельные таблицы (по ним ещё потом делать фильтры товаров).
Сделать таблицу для связи товара и свойства, в неё же добавить цену, остатки на складе и доступность позиции для продажи (если например анализируется информация от поставщиков).

Comments

[Hint]

Тогда придется везде таскать за собой id свойств (в корзине, в таблице заказов и т. д.). Плюс неоднозначная работа с такими базовыми параметрами как «цена», «количество».

[raskumandrin]

Заведите id в таблице для связи товаров и свойств. Этот id будет однозначно указывать и на товар, и на конкретную его модификацию. Таскать придётся только его.

[EugeneOZ]

raskumandrin, читали ли Вы про EAV? Знаете ли Вы про её недостатки?

[rPman]

Недостатки EAV неплохо решаются автоматически создаваемым кешем в виде классической таблицы поле->атрибут
Зато достоинства в виде гибкости — неоспоримы

p.s. по теме топика, каждый атрибут (я предпочитаю термин тег/метка) должен иметь возможность дополнительного свойства:
тег — 'вес', параметр тега: 200г
тег — 'цвет', параметр тега: 'красный'
тег — 'дополнительное украшение', параметры тега: цвет: 'белый', тип украшения: справочник 'Рюшечки'

Answer 2

[Алексей Сундуков]

Плюс неоднозначная работа с такими базовыми параметрами как «цена», «количество».

А в чем там проблема?

Answer 3

[alex_dm]

Я на одном из проектов сделал так:

product_category
product_group
product
product_attribute
product_attribute_value

Возможно product_group будет лишим, но в моем случае он был необходим (специфика товара).

Answer 4

[Сергей Полозов]

Собственно проблема в следующем: есть таблица товаров, есть таблица свойств к ним, допустим ищем по свойствам и находим 1000 различных id товаров - выдергивать из MySQL данные видимо таким образом (SELECT * FROM goods WHERE id IN (array)), где array - массив из 1000 элементов - пожалуй все согласятся, что такой запрос при посещаемости магазина даже в 1кпользователей в сутки и при размерах таблицы хотя бы в несколько десятков тысяч товаров - рушит систему, почем зря.

Решение с хранением товаров в альтернативных базах не рассматривается (т.к. допустим в документоориентированных подобный запрос отработает за константу по времени). Хочется услышать варианты именно с MySQL.

P.S. все предложенные выше - просто разновидности очевидного, не более того, особенно выложенный дамп базы - слишком много буков;) но по сути именно то, что я описал выше:)