Какие таблицы для продуктов (и их вариантов) в БД использовать?

Question

[weranda]

Приветствую вас.

В общем, есть продукт. Пусть это будут слоны. Как завести один конкретный продукт — дело понятное:

table.products:
----
- id (PK)
- name
- desc
- category_id > FK
- brand_id > FK
- ...

А вот вот когда появляются варианты, то появляется сложность — не могу выбрать вариант. То ли в одной таблице все хранить, то ли разделять на две и более. Рассмотрим два варианта. Предположим, что появляются варианты слонов: розовые и синие. Для справки: могут быть и единичные, весьма конкретные продукты без вариантов. К примеру, просто какие-то там слоны. Сначала был просто один слон, но потом завезли разных слонов или появилась необходимость разделить их на конкретных слонов.

Вариант 1: одна таблица для всех слонов.

table.products:
----
- id (PK)
- name
- desc
- category_id > FK
- brand_id > FK
+ parent_id > self.PK (NULL | int)
+ is_parent (BOOLEAN)
- ...

Вариант 2: две таблицы для слонов и их вариантов

table.products
----
- id
- name
- desc
- category_id > FK
- brand_id > FK
- ...

table.product_variants
----
- id
- parent_id > FK.table.products.id
- name
- desc
- ...

У продуктов будут еще и общие характеристики в таблице product_attribute_values. К примеру, если у родительского продукта есть заполненные поля каких-либо характеристик, то они будут такими же и у «вариантов» продукта, если не определены в конкретном варианте продукта.

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

Comments

[Adamos]

SKU продукта (слон) - SKU товара (розовый слон) - SKU торгового предложения (розовый слон со слоненком в нагрузку).
На прилавке - последнее.

[weranda]

Adamos, не очень понял. Могли бы пояснить чуть подробнее.

[Adamos]

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

[Adamos]

Но вообще-то лучшие практики для интернет-магазина на сайте - это CMS, в которой вся эта логика уже проработана.
Тема куда глубже и сложнее, чем кажется на первый взгляд.

[weranda]

Но вообще-то лучшие практики для интернет-магазина на сайте - это CMS, в которой вся эта логика уже проработана.
Тема куда глубже и сложнее, чем кажется на первый взгляд.

Adamos, я посмотрел несколько админок и БД нескольких CMS — кто во что горазд. Кто в одну таблицу пишет, кто — в две, кто — в большее количество, другие вообще не очень понятно как. Путей разных много, но хотелось бы обоснованно что-то выбрать, чтобы потом по минимуму переделывать при необходимости. Потому и спрашиваю.

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

Это как раз и есть второй вариант.

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

А вот тут не очень понятно то, зачем формировать третью таблицу. Данные уже же будут либо в одной таблице + джойны либо в двух таблицах + джойны.

Возможно, даже очень вероятно, что я не силен в проектировании БД, поэтому такие недопонимания.

Как бы вы реализовали и почему? Мне понятно, что вы написали про три таблицы, но получается так, что вы предложили третий вариант:) Теперь есть третий вариант и надо как-то определиться с выбором.

[Adamos]

weranda, в моем варианте как минимум семь таблиц:
- категории
- бренды
- продукты
- товары
-- свойства товаров
- торговые предложения
-- товары в составе торгового предложения

На самом деле, нет единой универсальной "правильной" схемы. Точнее, есть универсальные, но они далеко не всем нужны. Зависит от того, что у вас за товар и как вы им торгуете. У меня есть пара магазинов на Битриксе, где сделано поперек Битрикса, потому что товар имеет нестандартную логику, и предусмотренное в CMS чаще мешало ее реализовать, чем реально использовалось. У меня есть CMS по маркетплейсам - там свои погремушки, и именно там прекрасно понятна разница между товаром и торговым предложением, если у вас одна карточка - это не строго один товар...

Вы же дали совершенно абстрактную схему ни о чем, а спрашиваете, как сделать оптимально именно вам. Любой конкретный совет будет высосанным из пальца на основании предположений, для которых вы же не дали никакой базы.

И именно из-за того, что вы городите заведомый воздушный замок, еще раз предлагаю: отменить маниловщину и попрактиковаться на готовой схеме CMS. Любой. Чтобы потом вообще понимать, что делаете и зачем, а не городить велосипеды и не подпирать их костылями. Практически неизбежно.

[Adamos]

weranda, и насчет "в одну таблицу или в две" - мальки часто боятся сделать еще одну таблицу или, наоборот, разбрасывают одни и те же данные по нескольким. Так вот, правильность использования БД - не в количестве таблиц или столбцов, а в удобстве обработки данных в них. То есть чаще всего - в грамотной нормализации и подгоне данных и логики именно под реляционное хранение.

[weranda]

Adamos, не очень понятна штука «торговое предложение». Как оно реализовано? С продуктами и товарами все понятно, а вот с торговым предложением не очень. Конкретный товар всегда равен торговому предложению? Или только набор товаров == торговому предложению? Могли бы чуть подробнее объяснить?

[Adamos]

weranda, поищите OrangePi на Алиэкспрессе, например - довольно наглядно будет ;)
И немного фантазии - "два по цене трех", например, вы как товарами на витрину выложите?

[Everything_is_bad]

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

[weranda]

Adamos, т. е. можно продавать «товар» и «товарное предложение». И то и то по сути — товары. Верно?

[weranda]

Everything_is_bad, задачу озвучил в вопросе. Может быть не совсем корректно, но как мог. Хотелось бы сделать изначально правильно, чтобы потом не править все. Товаров может быть от 100 до 10000 разных (так, для наглядности).

[Everything_is_bad]

weranda, ты не задачу озвучил, а попытку своего решения, бизнес задачу надо рассказать

Answer 1

[ThunderCat]

У продуктов будут еще и общие характеристики в таблице product_attribute_values

Это же EAV? Почему там же не засунуть все эти типы слонов?

Comments

[weranda]

Извиняюсь, в БД не очень силен. Можно чуть раскрыть вашу мысль? Атрибуты больше относятся к характеристикам. Т. е. есть общие характеристики и характеристики конкретных вариантов. Вопрос тут больше про то, как лучше организовать слонов — в одну таблицу или две, чтобы можно было потом более или менее нормально выводить и «просто слонов» и каких-то «конкретных слонов» в таблицу.

[ThunderCat]

У вас есть атрибуты, которые по сути отображают кастомные значения типовых атрибутов (например длина слона, толщина хобота и тд). Почему тип слонов нельзя вынести сюда же (классический, розовый, карликовый...)?

[weranda]

ThunderCat, думаю, потому что не знаю. Как-то все запутанно. Характеристики, я полагаю, это какие-то базовые атрибуты товара, а варианты — это нечто вроде такой базовой штуковины, по которым различаются товары. Если взять iphone в качестве примера, то у него будут базовые модели=варианты pro, plus, e и прочее, а внутри уже будут конкретные характеристики. Надо же как-то потом выбирать товары из БД по каким-то основным критериям, а не искать среди множества разных характеристик. Сложно как-то, если подумать...

[ThunderCat]

weranda, По вашему описанию это больше похоже на модель, чем на разный тип слонов, с айфоном как-то более понятно о чем речь. Тут у вас надо понять - этот тип продукта это что-то типа модель? Айфон 13, 13про, 13 макс и 13 про макс все-таки разные продукты, в то время как 13 про макс розовый больше про свойства продукта

[weranda]

ThunderCat, Наверное, плохо объяснил. Постараюсь чуть развернутее. Давайте выберем что-то более конкретное для примера:

Категория = торты.
Бренд = михалыч.
Товар = торт ореховый.
Характеристики: запах = орех, цвет = зеленый, вес = фикс. 900 гр.
Варианты:
— делал сам михалыч (цена = 1500).
— делала жена михалыча (цена = 1200).
— делала гувернантка (цена = 900).
Т. е. у товара может быть характеристики общие и частные, а могут быть, так сказать, некие «генеральные» отличительные особенности, по которым формируется конкретный продукт.

[Akina]

weranda,

Варианты:
— делал сам михалыч (цена = 1500).
— делала жена михалыча (цена = 1200).
— делала гувернантка (цена = 900).

Это всё НЕ ВАРИАНТЫ. Это такие же атрибуты, как запах или цвет. Может, с одной разницей - не является обязательным.

Так что нужно сперва решить, это постоянные атрибуты или редко встречающиеся. В первом случае - поле в таблице, во втором - EAV или сериализация.

[weranda]

Akina, Если не подходит, то вот 100% варианты из жизни. Есть футболка и ее варианты:
XS / голубой 100 руб
XS / зеленый 100 руб
XS / графитовый 100 руб
S / золотой 100 руб
S / голубой 100 руб
S / зеленый 100 руб
S / графитовый 100 руб
M / золотой 100 руб
M / голубой 200 руб
M / зеленый 100 руб
M / графитовый 100 руб
L / золотой 100 руб
L / голубой 100 руб
L / зеленый 100 руб
L / графитовый 100 руб
XL / золотой 100 руб
XL / голубой 100 руб
XL / зеленый 100 руб
XL / графитовый 100 руб

[Akina]

weranda, я вижу два независимых атрибута - размер и цвет. То есть в таблице паттернов товара это два поля, ссылающиеся на соответствующие таблицы-справочники.