Как хранить товары с различными опциями в БД?

Question

[http80]

Существует такая задача:

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

Одна из категорий товаров подразумевает под собой некие "подписки" (т.е. товар один, но у него может быть несколько вариантов или опций - 1 месяц, 6 месяцев, 1 год, lifetime). Как хранить всё это в базе данных?

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

Что уже было предложено:
1. Создание отдельной таблицы под каждую категорию товара. Возможно, хорошее решение (т.к. категорий будет в худшем случае 10), однако всё ещё непонятно, как добавлять нужный товар, например, в корзину. Как понять, на какую таблицу ссылаться? Была также идея создания дополнительной универсальной таблицы "StoreItem", содержащей поля "item_id" и "item_category", то есть создание некой неявной связи с другой таблицей (на уровне софта понимаем, к какой таблице принадлежит item_category, и ищем в нужной таблице айди, равный item_id). Вроде должно работать, но мне это решение кажется несколько странным.

2. Создание универсальной таблицы "StoreItem" и дополнительной таблицы "ItemOption". На практике оказалось очень сложно управлять всем этим, да и таблица ItemOption не используется нигде, кроме как в этой категории.

3. Использование NoSQL. Как человек, который с NoSQL базами практически не работал, не совсем понимаю, стоит ли оно того, и если да, то нормальная ли это практика - совмещать реляционную и нереляционную БД? Где хранить корзины, заказы в таком случае?

Какое самое красивое / элегантное / практичное решение?
Заранее спасибо за помощь!

Answer 1

[Ипатьев]

В стародавние времена это действительно было проблемой.

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

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

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

На начальном этапе вы даже сможете делать поиск по атрибутам, используя нативные JSON функции. Но в дальнейшем поиск товаров, а так же фильтрацию по атрибутам на странице категории (так называемый "фасетный поиск") надо будет возложить на специальный поисковый движок (который тоже входит в широкую категорию "NoSQL", хотя ничего общего с документными БД не имеет, и БД, собственно, не является), такой как Эластик или Мантикора.

Главное при этом хранить (либо в коде, либо в таблице категорий) эталонные структуры таких json полей, которые, во-первых, использовать как справочники для заполнения товаров (тупо чтобы помнить, что частота процессора называется freq, а не frequency), и чтобы собственно делать фасетные фильтры.

Comments

[MVV]

Предложенное вами решение хорошо, если автору вопроса не требуется выбор по значениям атрибутов. Если требуется, то придется цеплять фактически полнотекстовый индекс (он, если чо, бывает и встроенным в/интегрированным с СУБД, например, у MS SQL) с поиском по нему, а ведение такого индекса и поиск по нему обходится дороже, чем по обычным для реляционной БД индексам по полям.

Но выбор - за автором.

PS

Тем более что в последние годы появилось вполне достойное решение: во всех классических СУБД появилась поддержка JSON полей.

Ну, а в предпоследние лет, эдак, 15-20 там появилась поддержка XML-полей - ровно для того же самого, просто тогда не было JSON а был XML. Это чисто к тому, что новое, нередко - это хорошо забытое старое.

[Ипатьев]

а ведение такого индекса и поиск по нему обходится дороже

Во-первых, это какая-то странная фантазия. Тоже что-то из стариковских воспоминаний о юности?
Во-вторых, у меня там написано, как организовывать поиск по параметрам в более-менее нагруженных системах

[http80]

Благодарю за развернутый ответ!

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

То есть пользователь может выбрать, какой конкретно товар (какого размера и цвета) ему добавить в корзину. При этом также у товара может и не быть таких опций. Именно таблицу с такими опциями я подразумевал в п. 2.
Таблица item_options содержала в себе ссылку на товар из основной таблицы товаров (store_items), а также JSON поле с параметрами (размер, цвет и т.д.). В корзине хранилось два поля: store_item_id и item_option_id.

Если прямо у товара в store_items хранить эти самые опции в JSON, то не совсем понятно, как в корзине хранить конкретный вариант товара, который был выбран пользователем?

[Ипатьев]

Ну здесь опять же два подхода.
Самый простой - это на каждый цвет и размер завести свой артикул.
Подписка на 12 месяц это один товар, а подписка на 1 месяцев - другой.

Если, по вашим словам, количество опций, как и количество товаров, сильно ограничено, то можно обойтись одной таблицей.
Но в реальности обычно оказывается, что опции все равно добавляются и их надо хранить отдельно.
при небольшом количестве категорий можно обойтись и eav. Но JSON в этом случае городить будет неправильно
Как я писал выше, таблица опций id-название(цвет, размер, срок подписки), таблица вариантов опций id опции-значение(красный, XL), и таблица опция-вариант-товар-количество. В корзину можно класть либо как у вас, id товара+id варианта опции, либо id из этой последней таблицы.

Если же использовать json поле в таблице товаров, то в корзине точно так же сохранить json с опциями.

[http80]

Ипатьев, Хм, действительно, вариант с одной таблицей для моего случая наиболее предпочтительный)
Всё оказалось сильно проще)

Благодарю за уделённое время!

Answer 2

[MVV]

Ответ на вопрос "как хранить" зависит от того, какие данные вы будете запрашивать. То есть - от представлений данных, с которыми работает ваша программа (программы). Именно на основе этих представлений синтезируется полная модель даннных, хранящаяся в БД.
В свое время, лет 25 назад, был (может, и сейчас есть) стандартизированный подход, называвшийся IDEF1 (это имя из стандарта) или Entity-RelationShip (это название процедуры), позволявший формальным образом синтезировать из этих, частных, представлений полную модель данных. И были программы, которые позволяли это делать. Я одной такой пользовался, ERwin называлась (AFAIK она жива и сейчас), но, в принципе, нужные процедуры можно выполнять и вручную. Описание процедуры на русском есть, как минимум одно, которое я знаю - в старой книге "Мартин Дж. Организация баз данных в вычислительных..."
Короче, синтез модели ваших данных - это ваша задача, связанная со специфическими вашими задачами.
Судя по информации из вашего вопроса, я могу только сказать, что:
1. этот вариант вам явно не походит: данные из представления "Товары в корзине" включают товары из всех категорий, так что отделные таблицы для каждой категории - это костыль: ходить можно, а бежать - уже нет.
2. В ItemOptions можно хранить данные для всех категорий - достаточно указать в каждой записи дополнительно к идентификатору товара идентификатор категории и идентификатор свойства. Потребуются ещё таблица категорий (идентификатор категории как первичный ключ плюс дополнительная информаци) и таблица свойств для каждой из категорий (идентифкатор свойства как первичный ключ, идентификатор категории - внешний, плюс дополнительная информация). Схема получается не очень уклюжая, но для работы в рамках реляционной модели более-менее годная (я когда-то такую и делал и с ней работал, но это было жутко давно). Насколько для вас такая схема пригодна - зависит от ваших моделей предствалений: например, будете ли вы в Корзине указывать дополнительную информацию из ItemOptions.
3. NoSQL - это название больше коммерческое, а не техничекое: оно включает много разных технологий хранения в БД, единственным общим признаком которых является, что они - не реляционные. Под эту задачу мне видится годным вариант навигационной БД (это где каждая запись содержит физические ссылки на связанные с ней записи): сетевая, например. В настоящее время такие БД иногда ещё проходят под псевдонимом "графовая". Но, опять же, смотрите на нужные вам представления, в данном случае - обращайте внимание на пути доступа к данным (эти самые ссылки): навигационные БД в этом плане не так гибки, как реляционные, и отсутствие нужных ссылок может заставить ходить по кривым путям и убить тем самым производительность.
Но это все теория, а что там сейчас на практике творится - я с уверенностью сказать не могу. Насколько я понимаю, там надо смотреь возможности конкретной СУБД - тем более, что производители часто называют их словом "гибридная", и надо понимать, что в этот гибрид попадает.

Comments

[Ипатьев]

Куча текста ни о чем.
http80 Зачем вы пометили решением этот поток сознания?
Решением надо помечать такой ответ, который поможет другим людям, у которых возник подобный вопрос. А кому помогут эти мемуары?

[MVV]

Ипатьев, видимо, автору этот поток информации помог, раз он отметил его ответом, вашего мнения не спросимши.
Ну да, много букв - но и я не из Спарты родом, так что мне, надеюсь, это простительно. Однако, если вы эти буквы осилили, то должны были бы обратить внимание, что кроме совета общего характера ("используйте процедуру IDEF1/ER"), там и решение, мое личное, предложено, и варианты решений, упомянутых авторами рассмотрены, в том числе - нужные ключевые слова для поиска подходящего (IMHO) типа NoSQL БД (а этих типов, как известно, много разных).

Answer 3

[Dmtm]

классическое решение:
таблица товаров, таблица опций, таблица связей товар-опция
NoSQL не нужен

Comments

[Ипатьев]

опция - диагональ телевизора. Может быть 14, может быть 84

[Dmtm]

и в чем проблема? две записи в таблице опций

[MVV]

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

[Dmtm]

категории решаются через таблицу связей, ну + таблица категорий

[Ипатьев]

Dmtm, насколько я понимаю, вы никогда с EAV сами не работали, а просто слышали краем уха про эту технику? :)

[CodeNull]

Ипатьев, эта "техника" применяется в каждой первой учетной системе. Что вас смущает в ней? Вполне нормально работает на десятках тысяч позиций с сотнями различных атрибутов. Решение выглядит лучше, чем тот же треш с nosql.