Как хранить корзину авторизованного пользователя в БД?
Добрый день!
Пишу свой велосипед, то есть - идеальный интернет-магазин (по моим представлениям). Сейчас реализован функционал хранения корзины любого пользователя в сессиях. Реализую (в процессе) сохранение корзины авторизованного пользователя в БД Mysql.
Столкнулась с рядом вопросов:
1) Сейчас таблица users_cart в БД имеет поля user_id, product_id, data(NOW()), count.
2) product_id получается составной, генерится из id товара и id характеристик разных типов. Получается что-то вроде '1-pd331-pp5-pp8' и тд, где 1 - id самого товара и остальное - характеристики с префиксами.
В сессии сейчас лежит полностью вся корзина - с idшниками и конкретными данными типа цена, название характеристик и их значение, название и алиас товара и тд.
Получается, когда я из БД буду вытягивать этот товар по сборному idшнику, мне потом опять все это распиливать на части, собирать по кусочкам из базы и вновь склеивать, чтоб отдать клиенту корзину из БД.... Дороговато профит выходит, много лишних обращений к базе и нагрузки на систему в целом.
Уже думала, чтобы корзину загонять в json формате в БД целиком и потом вытягивать, сверяя цены и кол-во с наличным. Но тут тоже куча возможных конфликтов.
Посоветуйте, пожалуйста, как сделать сохранение корзины в БД чистым и безболезненным, без кучи лишнего кода...
Почему I'd продукта составной?
Если у товара есть подварианты -- у них должны быть своя таблица, вариантов например и их уже в корзину их кидайте -- это правильный и распространённый легко расширяемый и обслуживаемый подход
id он на то и ид что является универсальным идентификатором, какие у вас могут быть характеристики которые не привязаны к ид? Свойства как наборы атрибутов в отдельной таблице, тогда по ид все легко вытаскивается. Соответственно и хранить только ид(можно еще цену продажи, а то она может поменяться, и будете гадать почему там суммы разные)
У меня так задумано, что характеристики могут быть нескольких типов, например - зависимые. Так цвет зависит от размера и ботинки 45 размера красного цвета могут отличаться по цене от ботинков 41 размера черного цвета той же самой модели. То есть реализована связь - родитель-ребенок-цена, кол-во.
Другая таблица характеристик заточена на то, что виски Red Lable объемом 0,5л, 0,7л и 1л. продается по разной цене. Соответственно таблица уже иная, без родительской взаимосвязи характеристик. Она вообще может не зависеть от цены и включать выборку товара по гендеру.
Я пыталась сделать по-правильному одну таблицу, но с моими хотелками это не вышло, пришлось делать 2 таблицы характеристик, отсюда - составной id конкретного товара. Зато обеспечена максимальная гибкость.
Храните товар как сущность (выделите все общее) а характеристики храните отдельно в таблице. Каждая характеристика будет у вас иметь, например, свою цену. Т.е базовая цена товара, плюс цена характеристики.
При добавлении товара в корзину, делаетй "снепшот" в базе, т.е
Примерно так мне и подумалось. Характеристик у товара может быть неопределенное кол-во, я буду хранить сущность самого товара в json формате рядом с этим составным своим id-шником. И вытягивая, буду иметь под рукой сразу все данные о товаре в одном флаконе. Останется только взять текущую цену и проверить наличие на складе, а они всегда в одной таблице.
А как у вас реализован учет товаров с разными атрибутами (разным размером, цветом и т.п.)?
Типа: большая зеленая коробка и маленькая красная, это у вас один товар или два?
Ответила в предыдущем комменте. Размер - родительская характеристика, цвет - дочерняя. Если артикул один - будет один товар в БД таблице products, а на странице собираться с учетом всех характеристик, включая изменение по цене.
ThunderCat, А почему бы их не связать? Если мне приходят на склад абсолютно одинаковые ботинки одной модели, отличающиеся только размером и цветом, плюс, на часть из них разные цены в зависимости от цвета, размера или другой прихоти поставщика, я реализую зависимость размер-цвет-цена-кол-во на складе. По-моему это логично...
Если мне приходят на склад абсолютно одинаковые ботинки одной модели, отличающиеся только размером и цветом,
По моей логике это разные товары, ибо я не могу все их сложить в кучку и сказать - вот, Вася, выбирай, это абсолютно одинаковые ботинки! По тому что эти - красные, а эти не налазят на Васю. Это действительно РАЗНЫЕ товары. Их и считать придется отдельно, иначе пересорт по размеру и цвету обеспечен. Вы просто не будете знать каких товаров сколько осталось.
PS: Я отказываюсь жить в мире без цветовой дифференциации штанов ботинок!
У меня реализовано так:
Ботинки мужские, Модель 15. - id товара - 15
- размер 42, цвет - черный , цена - 6000, кол-во - 9 id - характеристики 323
- размер 42, цвет - синий , цена - 6000, кол-во - 5 - id характеристики 324
- размер 44, цвет - черный , цена - 6500, кол-во - 7 - id характеристики 325
ИТОГО составное id товара может быть 15-pd323, 15-pd323, 15-pd324
Если нет родителя:
Виски Ред Лейбл:
- объем 0,5л, цена - 1200, кол-во - 6
- объем 0,7л, цена - 1800, кол-во - 4.
ИТОГО составное id товара может быть 14-pp32, 14-pp33
А может вообще не быть влияющих характеристик у товара и тогда там только id товара без никто+цена, кол-во.
- Обычно атрибуты, это отдельная сущность. т.к. заранее не известно, сколько пользователю нужно атрибутов и каких. Каждый товар имеет свою id-шку, по которой он уже вытягивает связанные с ней атрибуты.
т.е. в таком случае, из вашего примера :
Ботинки мужские, Модель 15. - id товара - 15
- размер 42, цвет - черный , цена - 6000, кол-во - 9 id - характеристики 323
- размер 42, цвет - синий , цена - 6000, кол-во - 5 - id характеристики 324
- размер 44, цвет - черный , цена - 6500, кол-во - 7 - id характеристики 325
Это будет три разных товара.
В таблица у товара, хранить только глобальную инфу, которая нужна любым товарам:
id, название, описание, цена, статус, кол-во, дата добавления, обновления. (может что-то еще)
А конфигурация этих продуктов (цвет, размер и т.д.) уже хранится в атрибутах.
Например таблицы атрибутов:
ид, ид_товара, имя_атрибута, значение_атрибута
Тогда можно сделать любое кол-во атрибутов для товара, и выгружать их по необходимости по ид_товара.
Но это только как пример.
Еще как вариант, вы можете посмотреть как это реализованно в простых cms (например opencart)
P.S. если это не секретная инфа, могли бы поделиться ссылочкой на репозиторий. Просто интересно посмотреть. Если что, можно на почту 32x1191@gmail.com =)
ipokos, Я правильно понимаю, что в глобальной таблице products, где как раз собраны общие вещи типа название товара, алиас, принадлежность к категории, описание и тд будет по Вашей логике, на каждую разновидность товара в зависимости от цвета-размера, свой ИДшник?
Нет, ИДшники не изменятся (как ботинки модель 15 42 размера черные были, так они и останутся), а вот вопрос хранения истории изменения цен и наличия остатков с определенной ценой- актуален. Но под это будет другая таблица и другая логика.
Анна С., То есть в вашей системе админ не может редактировать добавленные товары?
Что будет если производитель вдруг изменить ботинки модель 15 42 размера черные на ботинки модель 15 42 размера темно-темно-синие? :)
Или название товара с ботинки, на ботиночки?
Админ соотвественно изменит этот же товар, с этим же артикулом.
Редактировать все можно, но в случае ботинки-ботиночки это исправление на уровне заголовка, которое даже в сео ничего не затронет толком, ибо тайтл останется прежним, а вот черный никак не равно темно-темно синий, это будет уже 51 оттенок серого)). И я буду доторговывать остатками черных со своего склада, заведя при этом от поставщика новые темно-темно-синие как другой цвет.
Я понимаю, что все сложно предугадать, с этим столкнулась в книжной сфере, когда у разных торговцев одна и та же книга называлась по-разному. Занося товар в систему на автомате, вообще лишаешься подчас гибкости.
