Как лучше хранить список товаров заказа?

Question

[Артём]

Здравствуйте.

Как лучше хранить данные о участвующих в заказе товарах, если предполагается, что купленные товары со временем будут изменены, но данные товаров в заказе должны быть неизменны?

Пример:
Оформили Заказ1, в котором есть Товар1 со стоимостью 100 рублей.
На странице Заказ1 отображается Товар1 со стоимостью 100 рублей.
Администратор изменил стоимость Товар1 на 200 рублей.
На странице Заказ1 должен отображаться Товар1 со стоимостью 100 рублей, не 200.

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

Как вы решаете подобные проблемы?

Answer 1

[Алексей Уколов]

Первое что приходит в голову, хранить полную либо частичную копию купленного товара на момент оформления заказа

Ещё один вариант - использовать Event Sourcing, но у него те же самые проблемы, плюс тот факт, что нужно всё приложение под него переделывать. Или просто вести лог изменений и получать срез на нужный момент - Event Sourcing на минималках.

Другого варианта нет - старые данные нужно хранить, чтобы их использовать в дальнейшем. Можно хранить только какие-то основные поля: цену, название и т.п., чтобы уменьшить объём. Но нужно понимать, что чем больше данных вы храните, тем больше у вас в будущем возможностей для манёвра - вывести какую-то дополнительную информацию, посчитать статистику и т.п.

Я обычно либо завожу прям отдельную таблицу для товаров оформленных заказов, в которой дублируются данные, либо в корзине завожу json-колонку, в которой хранится срез на момент оформления. Логирование при этом тоже ведётся, но его неудобно использовать. Да и логичнее один раз "вычислить" значение и навсегда его сохранить, чем каждый раз дёргать из логов (и всё равно так же хранить в кеше).
В случае с json-колонкой мы сначала хранили вообще всё - модель и связанные с ней - с большим запасом. А примерно через полгода, когда начали упираться в размер данных, проанализировали кейсы и оставили только нужные поля.

Comments

[Иван Шумов]

Event Sourcing

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

старые данные нужно хранить, чтобы их использовать в дальнейшем

надо понимать зачем мы это делаем. Для логов или аналитики - ладно, для версионирования и возможности отката для пользователя - ладно, а для всего остального не нужно)

Ну и не забываем - машину по вчерашней цене вам никто не продаст

[Алексей Уколов]

Иван Шумов, вы, очевидно, не поняли проблему, которую автор хочет решить. Я понял, потому что с этой проблемой сталкивался.

Answer 2

[Иван Шумов]

1. Хранить историю изменения товара
2. Перед покупкой проверять не ушла ли текущая копия товара в архив
3. Предупреждать пользователей в случае если что-то изменилось
4. Оплачивается весь заказ на полную сумму, поэтому не важно с момента начала проведения оплаты изменилась ли стоимость единичного товара

Профит

Comments

[Алексей Уколов]

В вопросе речь про историю заказов, а не про процесс оформления.

[Иван Шумов]

Алексей Уколов, я объясняю причины, а не следствия. Какой смысл от того что я дам решение которое не имеет под собой никакой пояснительной базы?

[Алексей Уколов]

Эмм... Предыдущий комментарий нейросеть сгенерировала? Какие причины, какие следствия?
Решения, конечно, нужно аргументировать, тут никто не спорит. Но предлагать решение нужно для той проблемы, которая в вопросе содержится, а не для той, которую вы придумали.

[Иван Шумов]

Алексей Уколов, вопрос просто не о том как хранить данные, а как бороться с событием когда изменилась стоимость товара во время оформления заказа. К технологиям вопрос вообще не имеет отношения. Тут все о бизнес-процессах. И правильный ответ - никак

[Алексей Уколов]

вопрос просто не о том как хранить данные, а как бороться с событием когда изменилась стоимость товара во время оформления заказа

Так я и говорю - у автора вопрос не в этом. У него пример буквально начинается со слов оформили заказ. Прошедшее время.

[Иван Шумов]

Алексей Уколов, в мири e-commerce оформление заказа это не факт его оплаты) до завершения заказа он может меняться как угодно. Оформленный заказ это, по сути, корзина

[Артём]

Иван Шумов,

как бороться с событием когда изменилась стоимость товара во время оформления заказа

Таки нет, вопрос в том, как не позволить измениться записи о купленном товаре после оформления заказа.

Ваш первый пункт из ответа описывает решение этой проблемы (по смыслу похоже на Event Sourcing), остальное мне не интересно.
Спасибо.

[Алексей Уколов]

Я не меньше вашего понимаю в e-commerce. Из вопроса очевидно, что под оформлением понимается оплата.
Я не спорю, что кейс, описанный вами, валидный и должен быть предусмотрен. Но он не имеет отношения к тому, что спрашивается в вопросе.

[Иван Шумов]

Артём, это не отменяет моих слов. Привязывайте ВЕРСИЮ товара, а не его актуальное состояние. Иначе вы будете страдать при изменениях отображаемых полей в будущем, например. Можно, конечно, обойтись стоимостью и названием, но это, обычно, не работает