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

Question

[Toast]

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

Answer 1

[ugodrus]

Вы имеете в виду хранение атрибутов товара в корзине?

Comments

[Toast]

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

[ugodrus]

Я не знаю подробностей вашей реализации, но я бы сделал так:

Таблица корзины:
покупатель(ид)
товар(ид)
аттрибуты(строка, с перечислением атрибутов)
количество
и уникальный или первичный ключ на первые три поля

[ugodrus]

Но при таком использовании важно! чтобы атрибуты записывались в определённом порядке. Т.е. например сначала цвет, потом размер, и т.д.

[Toast]

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

[ugodrus]

Можно конечно сделать отдельной таблицей CartProductAttributes. Но я не думаю что это будет хорошо для часто изменяемых данных.

[Toast]

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

[ugodrus]

В том то и дело, что вопрос хранения в корзине и в заказе надо решать через учёт остатков. В конечном счёте красная майка размера M и красная майка размера L это не одно и то же. А уж тем более если еще и цвет другой. Таким образом майки одной модели - это не товар а группа, а сам товар - майка такойТоМодели красного цвета размер L.

[Toast]

То есть создавать товарные группы? И соответсвенно если пользователь заходит на страницу товара(товарной группы) он видит набор аттребутов и селекты? Но в любом случае хоть это и разные товары таблица аттрибутов и их значений должна быть привязана для МайкаА иначе, как искать различные аттрибуты если маек несколько размеров и цветов, не бегать же по каждому товару в поисках значений аттрибута.

[ugodrus]

Как у вас реализуется учёт остатков на складе?
В магазине, что я собирал, один товар - одна комплектация. Товары из 1С. В 1С также есть возможность ведения товаров по характеристикам (размер, цвет..). Т.е. как раз примерно то что у вас. Там учет ведётся по уникальной комбинации. Но я лично не сталкивался с таким.

Суть остается той-же. У вас должны быть уникальные товары. Вы можете конечно их группировать например по модели (предоставляя выбор цвета и размера). Но на выходе вы всё ровно должны получать уникальную единицу товара. Которая отразится на остатках и которая будет фигурировать в корзине и заказе.

[Toast]

Тут 1С нету, нужно реализовать учет. Пока остановился на схеме, где есть таблица Product, ProductToAttribute и таблица ProductToAttributeToValue, для однозначной идентивикации вводится SKU, а точнее ProductToAttributeToValue получает уникальный ключ и становится тем самым SKU уникально идентифицирующим продукт. Преимущества - легкость выборки аттрибутов для product_id (так как у похожих маек он все же один, но каждая майка имеет свой SKU).

[ugodrus]

В 1С есть такая фишка учёт по характеристикам. Так вот при включении такой опции 1С сама плодит товары. Т.е. При создании товара, если вы добавляете к нему характеристики, 1С сама плодит подобные товары при этом сохраняется первичный буквенно-числовой ключ товара, а для подсущностей (товары с конкретными значениями характеристик) создаётся суффикс (контрольная сумма характеристик и их значений). И когда происходит поступление или списание остатки ведутся по конкретным сущностям в базе товаров. Вроде как товар один, а на самом деле их много. Как раз ваш случай.
Думаю надо копать в сторону хранения товаров и их атрибутов чтобы реализовать то что вы хотите. А для корзины и товара в заказе достаточно приведенного мной примера. Если вам удастся совместить код товара и контрольную сумму по атрибутам - то даже поле атрибуты в этих таблицах вам не потребуется.

Answer 2

[Sergey Romanov]

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

Если вы их туда привяжете, после оплаты только статус заказа изменится, а все атрибуты будут сохранены.

Часто бывает так что атрибуты так же влияют на конечную цену. Например, белый цвет может стоить на $5 дороже. Так что хранить атрибуты надо соответственно. Хотя с тем стилем что я сейчас делаю, я бы их просто сохранил как упакованый json в отдельном поле attributes.

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

Comments

[Toast]

Но также надо вести учет товаров, так как товары есть красного цвета, есть синего, понимать, что есть на складе чего нету. Что касается корзины и заказа, то да, это отдельные сущности в таблицы, к заказу привязана корзина (адрес, способ платежа и тд). Пока остановился на SKU (но id_product один для похожих товаров) так как это позволит однозначно находить товар. А сами аттрибуты имееют поле с доп ценой (если имеется), так как некоторые аттрибуты есть доп опции, помимо красный синий еще есть товары "с опцией / без" и тп.

[Sergey Romanov]

Короче есть 2 атрибута товара. Первый это список как бы возможноых воборов атрибутов. А второй это то что выбрал покупатель. Мы о чем гооврим? Если о просто возможноых вариантах, то и хрнаить их надо с продуктом. Есил о выборе покупателя, то и хранить это нгадо с заказом покупателя.