Задать вопрос
@RusMits
проектирование-баз-данных

Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

Пример товара:
Товар А, Размер S, Цвет красный, 5000 руб
Товар А, Размер L, Цвет красный, 4500 рублей
Товар А, Размер XL, Цвет красный, 3000 рублей
Товар А, Размер S, Цвет синий, 3000 рублей
Товар А, Размер L, Цвет синий, 3000 рублей
Товар А, Размер XL, Цвет синий, 5000 руб

Подскажите структуру базы данных для оптимального хранения этих данных.
  • Вопрос задан
  • 2194 просмотра
2 комментария
Подписаться 4 Простой 2 комментария
Пригласить эксперта
Ответы на вопрос 3
alex-1917
@alex-1917
Если ответ помог, отметь решением
Это опции (схема моя, используется в ОДЕЖНОМ магазине друга))) )
spoiler
5c88f3c72a3e5115432325.png


хотя в 90% магазинов более сложная схема с опциями, типовая так сказать, но по факту все возможности этой типовой схемы используются редко, зато долбит сервера метко:
spoiler
5c88f45b72e78242290790.png
Ответ написан
Комментировать
Комментировать
@abmanimenja
Зависит от целей и понимания своих целей заказчиком.

Нужен ли ему поиск по любому слову в названии или только по точному соответствию начала слова?
Важно ли ему чтобы разные по цвету и размерам товары выводились на одной странице, а там дальше через выпадающий список выводились бы варианты товара?
Или все разные по цвету/размеру товары - это отдельные страницы на сайте?
Важно ли ему отслеживать количество и выводить только то, что есть в наличие?
Или может быть для целей SEO важно выводить всё всегда, но из размеров/цветов только то, что есть в наличие?
Могут ли характеристики еще добавляться (не только цвет и размер)?
Единая ли сетка размеров на все виды товаров?
Будет ли товар с разными размерами/цветами иметь разную цену или цена одноименного товара всегда одинаковая, независимо от цвета и размера?
Каковы требования к скорости работы/стоимости разработки (можно очень заточить скорость, но это больше мозговых усилий)?

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

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

Если делать по уму, то вам нужен не реляционная PostgreSQL, а СУБД Full-text-search (SphinxSearch, например).
Как раз для подобных структур данных СУБД типа FTS и выдаст максимальную скорость поиска.

Причем она подходит как для поиска по части названия, так и для поиска по характеристикам.

Впрочем, можно попытаться прикрутить FTS встроенный в PostgreSQL.
Ответ написан
17 комментариев
17 комментариев
@FRiMN
У амазона и таобао (алиэкспресс) структура примерно следующая (по крайней мере они так отдают в апи).
Дока Амазона
Пример данных о товаре Амазон
Пример данных о товаре Таобао

Есть основной товар. Обычно у него нет никаких характеристик, но есть цена, скидка, картинки, описание и т.п.
Товар входит в одну или более категорий. Если категорий больше одной, то есть одна основная.
Основной товар может иметь список дочерних товаров. Все товары, как основные, так и дочерние имеют идентификаторы, разница только в ссылке на родителя -- основной товар амазона ссылается сам на себя.
У таобао нет дочерних товаров, все варианты комбинаций характеристик (SKU, OtapiConfiguredItem в примере) описываются внутри основного товара.
В результате у амазона все варианты товара независимы (имеют разные урлы), у таобао все привязано к одному товару (и урлу).
У таобао всегда у товара один магазин. У амазона их может быть несколько, и у каждого соответственно свои цены, скидки и способы доставки.

В общем очевидно, что виды характеристик лучше хранить отдельно (хотя можно денормализировать). Так вы получаете возможность работать с ними комплексно (например вы легко сможете видеть все возможные варианты для каждого вида). Вероятно то же самое стоит сделать и с вариантами этих характеристик.
Не пытайтесь sku или характеристики хранить json'ом )).
Так же большой вопрос, меняется ли у вас название товара или описание, свойства, картинки и т.п. в зависимости от набора характеристик (так раньше было у dx.com).

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

Я бы старался держать таблицу с товарами маленькой (в смысле количества колонок и их объема). Вообще проще оперировать маленькими объемами данных, чем пытаться что-то отфильтровать в огромной таблице с кучей индексов и полей.

Статистику по товарам тоже храните отдельно. Описание, если оно большое, храните отдельно. Если у каждого товара большое количество изображений, возможно их тоже стоит хранить отдельно.
Ответ написан
Комментировать
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Разработчик баз данных PostgreSQL
Объединенные системы управления транспортом • Москва
До 220 000 ₽
DBA / Администратор баз данных PostgreSQL
СберТех • Москва
от 320 000 ₽
Администратор баз данных
LADA Цифра • Москва
от 220 000 до 270 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Геймдизайнер - просчет pvp боя (3 параметра) и накопление монет
23 апр. 2024, в 10:29
10000 руб./за проект
Помощь с С++ проектом
23 апр. 2024, в 10:24
2500 руб./в час
Залить товары и опции на сайт Опенкарт
23 апр. 2024, в 10:05
5000 руб./за проект
Ещё заказы