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

Question

[mewithoutyou]

Хочу понять, как сделать хранение данных о заказе в кафе, если товары могут быть удалены.
Например, заказ сохраняется в базе как подобная структура (у нас используется MongoDB).

{
	"id": 1,
	"name": "Client",
	"phone": "79000000000",
	"address": "Address",
	"comment": "Client comment",
	"products": [
		{
			"id": 1,
			"quantity": 1,
			"variation_id": 2
		},
		{
			"id": 3,
			"quantity": 2
		}
	]
}

Скажем, при открытии заказа клиента мы просто делаем выборку по id продуктов и выводим информацию. Но что делать, если позиция или ее вариация была удалена (как пример - сезонные меню каждые 3-4 месяца, и так далее). Какие здесь есть практики? Переносить в отдельную коллекцию такие позиции? Но тогда запрос будет выглядеть не таким уж гладким - надо будет искать id товаров, которые не нашлись в активных позициях и запрашивать из другой коллекции...
Я вижу варианты:
1) Либо удаление позиции заменить сменой статуса на Не активна и никуда не удалять, а на сайте фильтровать просто по параметру active: true (например);
2) Либо хранить в информации о заказе и название позиций и их вариаций.
Причем, мне кажется что придется делать смешанный вариант из этих двух, потому что мне же еще нужно как-то хранить цены товаров на момент покупки, плюс примененные скидки, если будут.

Comments

[sim3x]

Зачем вам монга?

[mewithoutyou]

sim3x, монгу я принял как эстафетную палку от того, кто написал уже часть функционала с ней, ну и конечно же я тоже разбираюсь только в монге :)

Безотносительно типа базы есть предложения?

[sim3x]

mewithoutyou,

После перехода на постгрес, можно предпринять следующее
- сделать поле типа булеан и не удалять товар в реальности
- дублировать товар с описанием в json поле в таблице корзина

Answer 1

[alex-1917]

1. Как минимум цену ПРОДАЖИ хранить в заказе. Или где её еще хранить?
2. Товары не удаляются, для этого придуман статус. (вообще в БД надо удалять строки как можно меньше, у вас точно не проект уровня МВИДЕО, накладные расходы будут доли %%.)
3. В 80% коробочных магазинов в заказе хранится вообще полная опись - сам товар, цена, параметры, кол-во.

Внимательно присмотритесь к своему проекту - вряд ли у вас 300млн товаров и 10000 заказов каждый день...
Храните все в заказе.

Comments

[mewithoutyou]

Спасибо! Все верно, накладных расходов там можно считать и не будет вовсе :)

Answer 2

[Дмитрий Шицков]

удаление позиции заменить сменой статуса на Не активна и никуда не удалять

Правильное решение

P.S. Не очень(совсем не) подходящая задача для нереляционной БД.

Comments

[mewithoutyou]

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

[Дмитрий Шицков]

mewithoutyou, потому и в P. S., что с вашим вопросом прямой связи нет. В вашем случае будет хранение явно избыточной информации в БД(особенно если будете придерживаться второго подхода) и бОльшие накладные расходы в сравнении с реляционной БД.

[alex-1917]

Дмитрий Шицков, так точно!!))
Например, пришла новая партия футболок, размер 62 больше не поставляется, т.к. фабрика проанализировала и посчитала, что 62 размер невыгоден - и перенастраивать гильотину под другие лекала и рисунок переносить в другой раскладке и вообще материала больше уходит при той же отпускной цене.
Что делать? Конечно же, убирать 62 размер из продажи.
И тут опа - заказы, где хранится только айди товара, будут ссылаться на неактивную опцию (62 размер) - глюкс...

Answer 3

[Егор Живагин]

А почему бы вместо id не класть полное инфо о товаре (включая цены, ...) на момент совершения заказа?

Comments

[mewithoutyou]

это как один из вариантов, который рассматриваю...

[Егор Живагин]

mewithoutyou, это как раз наиболее подходящий для нереляционной БД вариант. Кроме того, я пока не вижу других решений вашей проблемы.

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