Как можно спроектировать базу данных интернет магазина с вариантами товаров?

Question

[Илья]

Доброго времени суток.

Может кто подсказать схему БД онлайн шопа с моделью EAV и возможностью комбинировать характеристики товаров в дополнительные сущности, которые могут иметь отдельную цену.

Система простая донельзя, но что-то туплю. Допустим у нас есть размеры товаров (колец) 15,16,17,18,...25 пускай, фишка в том что они могут иметь разную цену (расход драг.металла и другие причины ведомые только производителю). Конечно можно тупо создать одну дополнительную таблицу, где грубо прописать товарИД, размер, цена, это круто, но что делать если нужно скомбинировать еще с любой другой характеристикой, допустим с текстовым полем "камни". Уже получается другой вариант: Размер, драг.камень, цена.

Магазину 4 года, и сделан в комбинации MODx EVO + костыли. На практике такие варианты будут знаю точно, работа не пропадет даром. И да я понимаю, что делать очередной шоп на Laravel для многих не имеет смысла, проще скачать opencart или битрикс купить, но там будут другие заморочки (изначально хотели на opencart поставить, не подошел), от этого никуда не дется.

В гугле не забанили, гуглю как могу, но в основном простые схемы попадаются. Либо все характеристики вообще в одной таблице products, либо модель EAV, но при этом нет вариантов с разными ценами. В общем нужна помощь, консультация, моральная поддержка =). Ссылка на мою схему: www.laravelsd.com/share/ZjzprC (если что ее можно форкнуть и править если кому надо). Ее можно не брать за основу, просто набросал.

Comments

[Сергей Герасимов]

Для modx есть готовое решение - дополнение к minishop2 - msOptions. Может быть оно натолкнет вас на мысли

[Илья]

Сергей Герасимов, для modx evolution есть минишоп, не знал, думал оно только для modx revolution

[Сергей Герасимов]

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

Что ищут покупатели? Кольцо с бриллиантом, кольцо с сапфиром... Насколько часто приходят покупатели по запросу кольцо с камнем? Может и не стоит мешать в одну кучу?

Тем более с точки зрения Seo продвигать будет легче когда это разные товары

[Илья]

Сергей Герасимов, Кольцо с бриллиантом, кольцо с сапфиром с точки зрения покупателя это все одно кольцо, одна сущность один УРЛ, но с разными камнями. Так как оно даже выглядит одинаково yf 80% ибо оправа одна + оправа может быть изготовлена из белого золота, серебра, желтого золота (логично догадаться что от этого будет разная цена). При этом кольцо будет находится в разных категориях одновременно "кольца с белым золотом", "кольца с желтым золотом" итп. Представляете как удобно человек кликнул 1 раз на категорию, выбрал кольцо, попал в карточку и вдруг расхотел желтое золото и в зял дороже с белым, так как увидел что оно красивее. В дополнение к этому покупатель хочет выбрать кольцо с размером для своих пальцев. А вообще в идеале если такая комбинация характеристик существует, неплохо покупателю еще и показать картинку, как будет выглядеть кольцо с бриллиантом или опалом в белозолотой оправе. И покупатель не хочет кликать дальше по каталогу перебирая названия вида Кольцо %название%, размер %значение%, белое золото
Посмотрите в сторону https://www.kristall-shop.ru/eshop/card/0005cacc41... как минимум есть размер. Почитайте книги сами. За 4 года успешной работы в Москве мы успели прекрасно изучить поведение покупателей в данной теме. Отвечайте пожалуйста по существу.

[Сергей Герасимов]

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

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

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

[Илья]

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

[alex-1917]

Илья, кстати, есть жирная база из гугл-аналитикс по двум сайтам (инет-магазины ювелирки), так вот, готов уверенно вас опровергнуть, что клиенты, пришедшие по запросу с яши или гугла, редко меняют окончательный выбор касаемо оправы!! Вы щас человека запутаете, вынуждая его идти на преждевременную оптимизацию, а В РЕАЛЕ чел зашел в поисках золотого кольца с камнем - его он и купит, ну может камень по размерам поменяет. А вы описывает какую-то гипотетику, это наверное так студенты лазиют по сайтам 585 или как там их))) Где нормальные камни и золотишко, там никто так не лазиет, вы уж поверьте на честное слово!!!
а выбор размера - это никакой к черту не вариант товара! это опция... по вашему, получается, что автору вопроса придется вместо 20000-50000 товаров создавать на порядок больше!!!!

[Илья]

alex-1917, Яж про то и спрашиваю, как это реализовать, эти опции или варианты товаров - называйте как хотите, где будет любой набор значений, которые можно комбинировать между собой и выставлять цену + привязка к товару. 20000-50000 тут человек выше предлагал, забивая в базу товары с одинаковым названием и разными размерами. С этим согласен - не камильфо. Стандартный EAV позволяет сделать не ограниченое кол-во характеристик их типов и значений, но как опции такого рода из них сделать хз. Не доходит до меня именно логика этого всего. Конечно товар - сущность одна с одним названием и урлом, остальное только опции.

[Илья]

Как пример https://www.bronnitsy.com/catalog/i/koltso-obrucha... - тут видно при смене размера меняется артикул + цена (не на всех размерах), т.е как минимум эти характеристики как-то связаны в базе и привязаны к сущности. Это просто как пример, по идее, мало ли что на другом типе товара должно меняться. Например, у тех же цепей. Пример еще https://www.bronnitsy.com/catalog/i/braslet-ruchno... - меняется размер - цена - перечеркнутая цена - артикул. То есть это все как будето бы где-то записанная комбинация, запрос при смене цены идет аджаксом с параметрами в контроллер ['action'=>'price', 'attribute_id'=>133131] типо такого. Но по закону сохранения энергии =) в случае с мускулом и приведению к правильным видам, размеры не дожны дублироваться где-то еще в таблицах. Скорее всего товар имеет просто набор размеров, но с другими разными параметрами. И судя по всему сделано это у них на битриксе

[alex-1917]

Илья, 20000-50000 товаров - это без размеров, бать!!!!! если тут кто-то выше предложил 20000 с размерами, то сколько же уникальных товаров? 2000 что ли? это пшик, а не ювелирка!!! тогда примеры приводите не на ювелирке, продавайте детские кубики)))

[Илья]

alex-1917, во-первых я не понимаю какая вам разница, кто и что продает. Почему вместо ответа на вопрос вы пытаетесь все умничать. Мы сейчас НЕ разговариваем о рентабельности бизнеса. Во-вторых ювелирная продукция имеет свои ниши, в некоторых может быть не более 5000 товаров просто чисто физически нету производителей по стране для большего обьема. В-третьих пример я привожу именно на ювелирке, потому что сейчас магазин работает уже 4 года и продает ювелирную продукцию, причем имеет склад, закупку, и галерею в Москве, + есть собственное производство, а вы куда-то смотрите в теорию там про открытия магазинов по типу sokolov, тот же bronnitsy. Если у вас есть магазин на 50 000 + товаров и вы купаетесь в деньгах - рад за вас, но ответа на вопрос пока никто дать не может, хотя умничают все и не по теме. Неужели это прям так сложно реализовать.

[alex-1917]

Илья, я ж написал выше что отталкиваюсь от двух жирных магазинов.. хз что это - ваши 5000 товаров, сельпо какое-то))

[Илья]

alex-1917, Ну так и как там реализована эта система не поведуете с высоты вашего опыта? Пока по теме ничего одно сравнение органов причинных. Подскажите уж простым смертным с их "сельпо" как им построить то варианты/опции итд товаров то?

[Сергей Герасимов]

Илья, так умничать вы начинаете, например про evo и ms2.

Вот вам несколько схем: Альтернатива EAV, структура базы?

Answer 1

[Антон Шаманов]

грубо говоря:
products (id, name) - товары
features (id, name) - характеристики
feature_values (id, feature_id, value) - значения характеристик
product_skus (id, product_id, name, price, qty) - артикулы
sku_features (sku_id, feature_id, feature_value_id) - характеристики артикула

Comments

[Илья]

Спасибо за ответ, у меня получилось примерно то же самое (часть схемы без модели EAV), в 3 часа ночи собрал, утром смотреть было страшно =)

- SkuAttributeValues
sku_id = 1; product_id = 20; attribute_value_id = 1; // gem = 1
sku_id = 1; product_id = 20; attribute_value_id = 2; // size = 23;
sku_id = 2; product_id = 20; attribute_value_id = 3; // gem = 2;
sku_id = 2; product_id = 20; attribute_value_id = 4; // size = 22;

// Где attribute_value_id - значение характеристики из pivot таблицы

- SkuPrices
id = 1; price = 2500;
id = 2; price = 3500;
id = 3; price = 5500;

[Антон Шаманов]

Илья, ну тут нового особо ничего не придумать :)

[Илья]

Тут еще проблема с добавлением опций товара "налету". Так как при добавлении товара еще не известны все значения всех характеристик, а значения опций берутся оттуда =). Думал не делать дополнительные(дублирующие) значения, а брать из уже известных, то есть у товара всеравно будет 10 размеров разных, к примеру, и все они будут записаны в EAV сводную табличку.

Говорите не придумать? =)) А что есть все опции зафигачить JSON форматом в дополнительное поле таблицы с сущностями товара =)) Были и такие советы =)

[Антон Шаманов]

Илья, Хар-ки добавляются ДО создания товара - таблицы features, feature_values не зависят от product_skus, sku_features. После создания товара заполняются только pivot таблицы.
Дублирование данных в описанном Вами виде будет очень тормозить поиск по базе магазинов даже с 50-100к товаров.
Я сделал еще типы товаров которые помогают группировать хар-ки и создаю скажем для типа Одежда хар-ку цвет со своими значениями, а для телефонов - со своими, это позволяет избегать длинных списков и путаницы со схожими названиями хар-к.

А что есть все опции зафигачить JSON форматом в дополнительное поле таблицы с сущностями товара

Ну кажется PostgreSQL позволяет что-то подобное ;)
Есть еще варианты с избыточностью, но это для совсем бигдата :)

[Илья]

Да, группы характеристик будут. Сейчас не стал это включать в вопрос, там мелочь, нет смысла.

Ох как трудно все описать все в чатике, когда у самого нет четкого плана =). То есть, получается тут надо создавать отдельные списки для опций с вариантами значений (размеры изделия (кольца или цепи) + список значений) ? И комбинировать можно будет только их из заранее предустановленных значений ?
Допустим, мы где-то сделали список размеров и список возможных материалов, далее добавили новую опцию выбрали там размер, добавили (если нужно) поле "материал" - выбрали там из списка, и далее задали цену, QTY и прочие доп. атрибуты коих можно наплодить уже потом? Чем то смахивает на опенкартовскую систему

[Антон Шаманов]

Не совсем понял. У самого товара тоже есть хар-ки (общие), которые тоже хранятся в таблицах features/feature_values. К артикулам можно привязать любые не использованные в товаре хар-ки, обычно для используются хар-ки - списки, значения можно и на странице товара формировать в процессе заполнения товара и сохранять ajax'ом т.к. таблицы хар-к не зависят от товаров\артикулов, ajax вернет id созданных записей т.ч. с сохранением товара проблем нет.

[Антон Шаманов]

В 70% магазинов что я видел к артикулам привязывали 1-2 хар-ки, обычно это цвет и размер и данные значения предустанавливаются заранее просто потому что редко изменяются, а не по каким то техническим причинам.

[Илья]

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

[Антон Шаманов]

Илья, А что из себя представляют заранее НЕ определенные списки? Я бы посоветовал начать с UML диаграм, тогда многие вопросы отпадут на этапе проектирования. В любом случае идеала не существует и любой проект потребует в конечном итоге рефакторинга.

[Илья]

Антон Шаманов, Во тут пример сайт (помоему на битриксе) https://www.bronnitsy.com/catalog/i/koltso-obrucha... - меняется артикул и цена при смене размера кольца. Но если посмотреть в сторону аджакса при изменение поля select, перегружается вообще весь блок с характеристиками (как буд-то бы это вообще отдельная сущность SKU имеющая свои наборы характеристик и привязку к цене).

https://www.bronnitsy.com/catalog/i/braslet-ruchno... - тут меняется еще и перечеркнутая цена. То есть вполне может быть что при выборе размера товара происходит смена варианта товара с произвольными значениями характеристик просто указанных ранее или обьедененных в группу.

[Илья]

Антон Шаманов, Не успеваю Вам отвечать =) Смотрю, везде смотрю, строю диаграмму www.laravelsd.com/share/ZjzprC . Что-нибудь обязательно придет. + скачал базы опенкарта, EAV модикса, качаю битрикс =) ищу картинки Shema в гугле =)

[Антон Шаманов]

Вы путаете хар-ки и артикулы видимо, у меня в примере product_skus (id, product_id, name, price, qty) тоже имеет свою цену, кол-во и т.д. группа значений хар-к определяет активный артикул т.е. если цвет синий, а размер XL выводим данный артикула "синий XL", если желтый, то "желтый XL" и т.д. Я не стал делать связанные хар-ки, эту задачу всегда можно решить js'ом.

[Антон Шаманов]

Илья, диаграммы можно и на основе дампа построить, большинство cms магазинов имеет демо версии - cmsmagazine.ru/catalogue/shop , другое дело что многие из них имеют не характерные решения обусловленные средой разработки, например магазины на ждумле были очень странные, про вордпресс вообще молчу.

[Антон Шаманов]

Илья, я предпочитаю старый добрый workbench )

[Антон Шаманов]

Если это Ваша схема www.laravelsd.com/share/ZjzprC , то прямо скажу лучше начать сначала.

[Илья]

Антон Шаманов, Да вчера сервис этот нашел решил что-то набросать. Я просто до этого работал в основном с MODX EVO там EAV реализована вот так как на схеме.
3 таблицы: ресурс (сущность),
одна сводная (ресурс_ид, аттрибут_ид, значение текст поле) +
характеристики (тип(select,checkbox), название, возможные значения списком с разделителями
есть еще группы характеристик которые привязаны к шаблону (например товар/страница) что угодно - набор полей вида select/text и тд можно любые делать и в любом кол-ве. При том что сделано это просто дико универсально. Текущий шоп на модиксе имеет варианты размеров и цены, но это костылем сделано Может по этому отталкиваюсь от этой структуры начальной базы. Но это просто вариант. Сейчас фреймворк, сделать можно уже как угодно, это огромный плюс.

[Антон Шаманов]

Илья, простой пример, у тебя attribute_options имеет поля id, name, value - приведи пример с данными, product_attributes - value, attribute_id, products - articul. Все общем все уйня Миша, давай по новой! :)

[Илья]

Антон Шаманов, Она просто вспомогательная, убрал ее. Чтоб не мозолила глаза =) www.laravelsd.com/share/ZjzprC Полностью вам верю может и х...ня =) Но

Модель из трех оставшихся таблиц работает, Через реляцию (в ларавеле PIVOT table) легко выводит продукт + набор значений + название характеристик, но это примитив конечно, такая система сейчас стоит, да работает, но не то =) не серьезно. и кстати не поддерживает наборы опций заранее предустановленных (но это потому что просто нету дополнительного поля в таблице с типами характеристик - "options") это модиксовская схема, там В options можно вывести что угодно с разделителями и тип поля указать select, тогда система спарсит и выведет в виде html->select поля

[Антон Шаманов]

Илья, Ну чтобы оно вообще не работало надо постараться :) Не стоит добавлять поля пока необходимость в них не появится.

[Антон Шаманов]

Илья, я знаком с modx т.ч. можно не рассказывать - отличная система и пипец какие ужасные пользовательские плагины, а почему? потому что modx дает много свободы )

[Антон Шаманов]

Илья, кстати на том же сервисе висит готовый велосипед www.laravelsd.com/share/K5oG9a

[Илья]

Антон Шаманов, Да система там не похожа вообще помоему ни на одну ЦМС, они даже модикс обозвали CMF - от слова фреймворк. И отчасти правда, очень чистая дефолтная система, косяки есть, как и везде по типу view в базе, хотя, сомнительно, у меня некотррые клиенты спокойно редактируют шаблоны не парязь про фтп, IDE. 2 кнопки нажав. Очень слабая поддержка к сожалению именно версии MODX EVO - старой ветки развития

[Илья]

Антон Шаманов, посмотрел на велосипед =) Только не понял как там реализованы варианты, например размеров/цен. Помоему там не хватает еще 1 таблички - сущности товара, которая будет содержать хотябы УРЛ =)

[Антон Шаманов]

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

[Антон Шаманов]

Илья, url выстраивает роутер, на в качестве slug id или sku.

[Илья]

Антон Шаманов, На схеме можно левые поля не добавлять =) добавить их потом. К тому же SKU добавить что угодно, даты, активен/неактивен, и прочее по вкусу

[Илья]

Антон Шаманов, да, сейчас уже настроен роутер на поле slug ибо после переноса терять трафик поисковый благодаря новым урлам - совсем не камильфо =) Хотя да в новом шопе можно и по ИД и т.д. Но там схема простая по типу моей, такую сделать легко, без заморочек