Как в БД организовать хранение учета проданных товаров?
Добрый день
Цель:
Возникла необходимость хранить в БД учет проданных товаров.
Для чего:
В каждой категории (пример: телевизор, бытовая техника, сотовые телефоны) выводить самый продаваемый товар данной категории. Т.е. при просмотре каталога с телевизорами, блок "хит продаж" будет отображать самый продаваемый товар этой категории, т.е. самый продаваемый телевизор и т.д. по категориям.
Структура таблицы:
id (autoincrement)
product_id (id проданного товара, это торговое предложение) (int)
parent_product_id (id родительского товара) (int)
category_id (id категории товара) (int)
qty (количество проданного товара) (int)
Вопрос:
Как лучше сделать? Каждый раз делать запрос в БД или хранить общие данные по product_id в другой таблице? И по cron один раз в день пересчитывать количество проданных товаров?
Приведу пример как было с нашим магазином.
Сначала у нас было 10 000 ед. продукции и проблем не составляло при каждом заходе посетителя обращаться в базу и брать оттуда актуальные данные о том, что лучше продается.
Однако когда товаров стало 2млн и проект перешел почти что в high-load, было принято решение раз в полдня залазить в базу, для каждой группы товаров искать там наиболее продаваемый и сразу же строить кеш для отображения.
Так что всё зависит от того, какие системы вы используете, какую нагрузку, какое масштабирование. В каждом случае решения хороши по своему.
Я тоже так думал, что может быть кэшировать данные и пользователям из кэш отдавать.
А насчет того что раздельно хранить total число проданных единиц по товару? как думаете?
"Отдельности" всегда будут иметь место когда проекты очень большие, повторюсь, если в магазине 10к товаров или около того, то городить избыточности (выносить отдельно) не нужно
Сделать запрос после продажи. Допустим 1 раз вы взяли самый продаваемый товар и сохранили в каком то файле. После этого если не было не одного продажей нет смысла еще раз делать запрос поскольку ответ будет таким же. После продажи какого либо товара следует еще раз сделать запрос и .т.д.
Нет, вы не так поняли механику.
Пользователь покупает товар.
В админке когда статус заказа будет изменен на "Выполнено" идет запись в БД.
Записывается каждый товар который находился в корзине заказа.
Насчет выдачи данных и частоте запроса уже понял как сделать лучше, но вот теперь другой вопрос, стоит ли хранить общие данные количества проданных товаров т.е. сгруппированные по product_id идет запись в другую таблицу.
Количество продаж лучше сделать в отдельной таблице. Темь боле Вы там сможете и другие данные хранить. Допустим время покупки, id пользователя, естественно id купленного товара и т.д.
@kadirov вообще для этого обычно служит таблица orders, там же всегда лежит количество купленного товара, и, если статус ордера - доставлен, то этот ордер включается в обсчет популярности товара
плоховато, мое мнение, лучше это закешировать и обновлять раз в 4-6-8-12 часов, потому как когда пойдет пару сотен тысяч запросов в секунду, пересчитывать после каждой "продажи" будет ой. а еще ж есть интеграция с какой-то системой бухучета вроде 1с...
SELECT *
FROM (SELECT category_id,
ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY qty DESC) AS RowNumber
FROM table_name
) AS a
WHERE a.RowNumber = 1
Сложный
