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

Question

[RusMits]

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

Подскажите структуру базы данных для оптимального хранения этих данных.

Comments

[luna3956]

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

[alex-1917]

см. мой ответ ниже, вкратце таблицы:
опций: размеры, цвета, прочая
опция для товара: id товара, айдишки опции (23,45,843,...), цена для этой комбинации, у меня еще и остаток тут же (такая разбивка приходит от поставщиков)

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

Answer 1

[alex-1917]

Это опции (схема моя, используется в ОДЕЖНОМ магазине друга))) )

spoiler

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

spoiler

Answer 2

[abmanimenja]

Зависит от целей и понимания своих целей заказчиком.

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

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

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

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

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

Впрочем, можно попытаться прикрутить FTS встроенный в PostgreSQL.

Comments

[luna3956]

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

Держите в курсе.

EAV можно реализовать совершенно по-разному. Есть отвратительные реализации этой модели, которыми грешат многие разработчики, которые сводят на нет все преимущества реляционных СУБД. Но есть и правильные подходы, которые во многом зависят от предметной области.

Если делать по уму, то вам нужен не реляционная PostgreSQL

Тостер не место для холиваров, человек задал вопрос как решить задачу в контексте его стека, в данном случае это реляционная СУБД.

[abmanimenja]

luna3956,

EAV можно реализовать совершенно по-разному.

EAV и есть EAV.
"Совершенно" по-разному вы не реализуете.
Если вы что то совершенно по другому реализовали - то это уже не EAV.

Есть отвратительные реализации этой модели, которыми грешат многие разработчики, которые сводят на нет все преимущества реляционных СУБД.

В том то и дело, что EAV, на первый взгляд - идеально под реляционные СУБД.
И для хранения/редактирования данный EAV действительно удобен.
Для поиска же - очень плох.

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

Пример.

[abmanimenja]

luna3956,

Тостер не место для холиваров

Как это?

человек задал вопрос как решить задачу в контексте его стека, в данном случае это реляционная СУБД.

Он выбрал не лучшее решение (наверное потому что иных и не знает, все же реализация подобных структур с СУБД FTS, а не РСУБД - вещь менее известная).

[abmanimenja]

qoso,
А вы точно знаете, что такое EAV?
Из трех ваших примеров на EAV нет не одного EAV.

[abmanimenja]

qoso,

Лишаемся многих преимуществ реляционного подхода

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

[abmanimenja]

qoso,
о! а куда вы удалили свои ответы?
осознали?

[luna3956]

abmanimenja, в удаленном ответе все было более чем по существу(успел застать). А то, что Вы не увидели в тех примерах EAV, свидетельствует о пробелах в Ваших знаниях.

[abmanimenja]

luna3956,

А то, что Вы не увидели в тех примерах EAV, свидетельствует о пробелах в Ваших знаниях.

А почему вам не приходит в голову, что пробелы в знаниях у вас?

в удаленном ответе все было более чем по существу(успел застать)

Да, были предложены вменяемые варианты, не спорю.
Но ни один из них не EAV.

[luna3956]

abmanimenja, я готов дискутировать.
Вот фрагмент из книги "SQL Antipatterns: Avoiding the Pitfalls of Database Programming", который иллюстрирует плохую реализацию eav, которая для Вас "не eav":


Из этой же книги, из этого же раздела, целиком посвященного EAV, что вы тоже назвали "нe eav":


Рекомендую к прочтению, очень хорошо разжеван EAV со всеми своими плюсами и минусами.

Надеюсь на конструктив с Вашей стороны.

[abmanimenja]

luna3956,

Из этой же книги, из этого же раздела, целиком посвященного EAV, что вы тоже назвали "нe eav"

Давайте вы не будете мне приписывать то, чего я не говорил.
EAV - Entity–attribute–value model
https://en.wikipedia.org/wiki/Entity%E2%80%93attri...
Наш испарившийся друг qoso, описывал совсем другие вещи в своем удаленном посте.
Несколько как более примитивные/простые.

[abmanimenja]

luna3956,

я готов дискутировать.

Вот к этому пожалуйста приведите пояснения

Есть отвратительные реализации этой модели, которыми грешат многие разработчики, которые сводят на нет все преимущества реляционных СУБД.
Но есть и правильные подходы, которые во многом зависят от предметной области.

EAV достаточно определенная вещь.
Какие такие "разные правильные и неправильные"?
Примеры, пожалуйста.

[luna3956]

abmanimenja, попробую максимально упрощенно чтобы как можно более наглядно:

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

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

Пример неправильного воплощения/реализации Вы можете увидеть на первом скриншоте который я скидывал: там eav воплощен в виде таблицы вида сущность-атрибут-значение(в примере из книги это issue_id(сущность)-attr_name(атрибут)-attr_value(значение)). Такая реализация является крайне плохой, потому что приходится хранить все значения в виде строк, в том числе числа с датами, и все в одном столбце. При таком подходе мы не знаем типов значений, не можем вводить необходимости уникальности значений для определенных атрибутов и прочие вытекающие, то есть ни о какой целостности данных не может быть речи.

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

Еще один пример правильной реализации это создание для каждого подтипа отдельной таблицы. Этот подход хорош тем что сохраняются все преимущества реляционных СУБД, но уместно применим только когда количество подтипов не слишком большое. Вот описание подхода из этой же книги:



Это и есть те самые разные подходы, правильные и неправильные, где-то больше уместные где-то меньше, о которых я говорил.

UPD: пример плохой реализации о которой я говорил можете увидеть в ответе ниже пользователя alex-1917 на втором скриншоте, там как раз создана эта одна табличка где все хранится в виде строк(product_options_values)

[abmanimenja]

luna3956,

Пример неправильного воплощения/реализации Вы можете увидеть на первом скриншоте который я скидывал: там eav воплощен в виде таблицы вида сущность-атрибут-значение(в примере из книги это issue_id(сущность)-attr_name(атрибут)-attr_value(значение)). Такая реализация является крайне плохой, потому что приходится хранить все значения в виде строк, в том числе числа с датами, и все в одном столбце. При таком подходе мы не знаем типов значений, не можем вводить необходимости уникальности значений для определенных атрибутов и прочие вытекающие, то есть ни о какой целостности данных не может быть речи.

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

Незачем так париться.

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

И ввести колонку, указывающую на используемым в данном случае тип.

[abmanimenja]

luna3956,

Еще один пример правильной реализации это создание для каждого подтипа отдельной таблицы. Этот подход хорош тем что сохраняются все преимущества реляционных СУБД, но уместно применим только когда количество подтипов не слишком большое. Вот описание подхода из этой же книги

Это пример "полной реляционности головного мозга", простите.
То есть реляционность ради реляционности, лишь бы было все "по правильному", а зачем именно это нужно и каким потерям производительности/лишней нагрузке на мозги программиста (и увеличение вероятности ошибок) приведет - наплевать.

Не нужно боятся денормализовать, когда это целесообразно.

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

[luna3956]

abmanimenja, уважаемый собеседник, вопрос производительности выходит за рамки нашего диалога и уж тем более этого вопроса. Нормализованная база данных и высокая производительность стоят по разные стороны реки и зачастую принудительная денормализация лишь и спасает. Но опять же, это все выходит за рамки нашего диалога, мы говорили о правильной структуре и подходе к решению задачи "сущность с атрибутами", я Вам привел примеры правильных и неправильных решений в контексте реализации одной модели и искренне надеюсь, что Вы правда поняли эти примеры и узнали для себя что-то новое и интересное. Я ни в коем случае не отношусь к тем гражданам на айти площадках, которые уперто несут дичь до последнего лишь бы их эго не пошатнулось от того, что они великие могли чего-то не знать. Наоборот, всегда открыт к диалогам и обсуждениям и всегда с удовольствием черпаю для себя информацию и делюсь той, которая известна мне. Что же касается нормализации - последний раз я с нормализованными базами имел дело лет 8 назад и мне прекрасно известно, какой ценой достигается производительность) Но опять же - речь была о правильной структуре, поэтому я говорил о правильной структуре с точки зрения канонов. В общем, добра)

[abmanimenja]

luna3956,

пример плохой реализации о которой я говорил можете увидеть в ответе ниже пользователя alex-1917 на втором скриншоте, там как раз создана эта одна табличка где все хранится в виде строк(product_options_values)

А! То есть вы считаете "плохой" это если "не реляционный до мозга костей"?
А вопросы низкой производительности "правильного" решения вас не волнуют.
У него вполне себе вменяемый вариант, в реальном интернет-магазине на очень и очень многих видах товаров вполне можно обойтись и только строками в значении атрибутов.

[abmanimenja]

luna3956,

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

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

Answer 3

[FRiMN]

У амазона и таобао (алиэкспресс) структура примерно следующая (по крайней мере они так отдают в апи).
Дока Амазона
Пример данных о товаре Амазон
Пример данных о товаре Таобао

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

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

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

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

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