Как сделать товары с разными характеристиками и ценой?

Question

[darksladen]

Подскажите, как можно сделать товары, которые будут в разных вариантах? Соответственно у каждого варианта товара будут свои характеристики и цена. СУБД использую mysql.

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

На всякий случай пример свойств товара =)

Answer 1

[xmoonlight]

Такой вид товарного предложения называется "вариативное товарное предложение".

1. Создаётся унифицированный товар, как дополнительный подраздел в нужной категории товаров и, желательно, помечается флагом "унифицированный товар".
2. Создаются все доступные к приобретению варианты сочетаний, как отдельные товарные предложения.
3. В скобках наименования указываем все параметры попарно через двоеточие с разделением точки с запятой.
Пример: Портативный SSD (объем:128Gb;цвет:красный)
4. Затем, в эту категорию помещаются все созданные сочетания товарных предложений.
5. При отображении товара из категории "унифицированный товар" (или, если есть в наименовании товара двоеточие в скобках) - определяем, что товар - вариативный.
6. Если это так - делаем выборку, предварительно исключив скобки (или проще: все товары этой категории) из БД.
7. Если таких товаров несколько - отображаем варианты для выбора.
8. При изменении одного из вариативных параметров пользователем - меняем товар через ajax (или полностью перегружаем страницу, что хуже...)

Еще раз, повторюсь: если пометить категорию в п.1 не представляется возможным, можно просто ориентироваться на скобки и двоеточие, и создавать селекторы по этим признакам.

----------

Если делаете с нуля, всё просто:
1. Добавляете к разделу флаговое поле в БД: "вариативный товар"
2. Добавляете отдельную таблицу вариативных характеристик, в которой присутствуют связки:
ID раздела "вариативный товар", ID одной характеристики товара, тип поля (лучше ID поля и доп.таблицу, канешн, но не так критично, если вариантов не много)
3. Если товаров из нужного вариативного раздела с такими характеристиками у нас несколько - отображаем выбор параметров.
4. см. п.8 (из предыдущего раздела)

Comments

[darksladen]

Спасибо, это уже ближе, такой вариант тоже рассматривал, НО! Как быть с корзиной и заказами? Добавлять в них ид торгового предложение, и товара получается? Или есть ещё варианты?

[xmoonlight]

darksladen: у Вас всегда сайт работает ТОЛЬКО С ТОВАРОМ!
Вариативный товар - это СИСТЕМНАЯ СУЩНОСТЬ и никакого отношения к цене, корзине и покупке ВООБЩЕ НИКАК не имеет.

[darksladen]

Здесь вы меня вообще запутали! Как это не имеет если именно этот товар будет покупать клиент?

[xmoonlight]

darksladen: он не может купить "Портативный SSD" без объёма и цвета)))
Он только может купить с конкретным объёмом и цветом)

[darksladen]

Я про то и говорю, он будет покупать по сути торговое предложение же верно? Вообщем у меня сейчас такая схема: есть товары, они привязаны к какой то группе, группа имеет несколько атрибутов. Также есть торговые предложения, которые привязаны к товару и на основе группы генерируется форма с атрибутами этой группы.. Но есть 2 проблемы - 1) эта схе а не предусматривает товары без атрибутов, так как тогда как раз придётся добавлять в корзину помимо торгового предложения ещё и сам товар, что геморойно.. 2) значения атрибутов хранится в json поле в таблице с предложениями, так что нормальным путём нельзя сделать фильтр по ним. Что скажете?

[xmoonlight]

Я про то и говорю, он будет покупать по сути торговое предложение же верно?

Нет, не верно.
Кликать в списке товаров - он будет по торговому предложению, а вот открываться (сразу после клика) - будет один из товаров из раздела "торговое предложение".
Покупать он будет тоже один из товаров, который находятся в том же разделе (где и он сам) с флагом "торговое предложение".
Т.к. отображается у него - КОНКРЕТНЫЙ ТОВАР.

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

[xuBpaloLim]

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

[xmoonlight]

xuBpaloLim, Поясните: из-за чего проседает скорость?

[semki096]

xmoonlight, не подскажете где можно более подробно почитать об этом, может схему таблиц посмотреть, потому что не могу понять структуры и как это работает.

Answer 2

[d-stream]

Вчера я закупил колбасу по 180руб, позавчера была по 175, завтра обещали подогнать ворованную по 70...

общий намек понятен? (товар-партия-прайс-время)

Comments

[darksladen]

При чем здесь это? Цену меняют не просто на колбасу, а на докторскую, которая весит 200гр.. Объясните, может я что то не понял оО

[d-stream]

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

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

[darksladen]

Ну в том то и вопрос как организовать товары и их схожести! Вы можете в контексте mysql пояснить как хранить это все? Пока вы только сказали, что схожий товар должен иметь артикул, что и так понятно ;)

[d-stream]

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

для первого варианта - классика 1:N, для второго - N:M

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

Answer 3

[Никита]

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

Такое заполнять удобно - когда вставляете или обновляете товар, то просто нужно проставить галки к каким категориям он относится. Например, белый, 50мл.
Удобно отображать картинку и название товара, да и искать по фильтру также просто.
В корзину попадает конкретный товар и никаких морочек с атрибутами, подсчетом цен и прочим.

В итоге как схема понятна - можно "категории" переименовать в "аттрибуты" , смысл от этого не меняется.

Comments

[darksladen]

У меня проблема в том, что у таких товаров много одинаковых свойств, такие как title, seo и т.д.. Да даже фотки одинаковые будут.. Таким образом надо все же как то к товару умудриться присобачить это.. А на счет галок для отметки свойств интересно, так наверное и сделаю

[rusnimex]

Позвольте узнать, что имелось в виду?

искать по фильтру также просто

Как мне найти товар у которого цвет "белый"? Использовать like и искать в поле "свойство"?

[Никита]

rusnimex: искать товары, принадлежащие категории(аттрибуту) "белый".
WHERE attr_id =:id, где id - идентификатор атрибутов

[rusnimex]

Никита: т.е. при сохранении строки вида "категория1:название1; категория2:название2" сохранять в таблицу таким образом "insert into categoryTable values ("категория1", "название1") ?

[Никита]

rusnimex: нет. Я ж условно написал. Конечно нужна доп таблица, связь на самом деле N:N.

Answer 4

[xuBpaloLim]

Если своя характеристика и своя цена и их не нужно объединять при поиске, то никаких причин делать это не как отдельные товары нет.

Answer 5

[Aset]

Других вариантов пока не нашел
https://en.wikipedia.org/wiki/Entity%E2%80%93attri...

Comments

[darksladen]

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

[Dave]

darksladen: Вообще не правильно рассуждаешь. Все просто здесь - создаешь таблицу с аттрибутами и ценой. Например attribute_name | attribute_value | price - если аттрибут может влиять на цену, то в таком случае прибавляешь значие из столбца price к основной цене товара

Answer 6

[aynur_safin]

Можно задавать товару базовую цену и в отдельной таблице цену атрибутов товара в абсолютных или относительных значениях. Например:
товар Колбаса: 100руб, сорт Докторская: 10 руб или коэф.1,1, вес 400гр: -60руб или коэф.0,4, итого 100+10-60=50руб или 100*1,1*0,4=44руб.

Вторая идея - хэшировать набор атрибутов и задавать ему цену.

Comments

[darksladen]

1 вариант не подходит.. По 2 два вопроса:
1) как хранить эти атрибуты.
2) как хэшировать.

[aynur_safin]

darksladen:
Ну навскидку примерно так: Атрибуты храним в отдельной таблице: (товар_ид, атрибут_ид, атриьбут_нейм), храним только атрибуты влияющие на цену, и в отдельной таблице храним хэши от номеров атрибутов и их цену (товар_ид, хэш, цена). А чем хэшировать, сами выбирайте. Т.е. хэшируем любое сочетание атрибутов, если нужно узнать цену сочетания, хэшируем и находим в таблице хэшей цену.

[darksladen]

Но тогда в дальнейшем будет невозможно сделать фильтр или поиск по значениям атрибутов верно? Значения же и будут составлять этот хэш?

[aynur_safin]

darksladen:
Надо подумать, возможно нужно добавить в таблицу хшей список атрибутов со значениями вида 12:34, где 12 и 34 номера атрибутов и значений, хотя это получается и будет хэш )) по нему и можно фильтровать.

Answer 7

[semki096]

Ещё вариант логики https://drupalcommerce.org/user-guide/product-attr...