Существует ли лучшая практика хранения данных для объекта базы данных (модели), который изменится или будет удален в будущем (Django)?

Я создаю систему управления заказами для интернет-магазина и хотел бы хранить информацию о заказываемом продукте.

Теперь, если я использую связь Foreign Key с продуктом, когда кто-то изменит цену, бренд, поставщика и т.д. продукта или удалит его, это повлияет и на заказ. Я хочу, чтобы система управления заказами могла отображать состояние продукта, когда он был заказан, даже если впоследствии он будет изменен или удален из базы данных.

Я долго думал над этим и придумал такие идеи, как хранение строкового представления объекта в формате JSON; создание дубликата продукта, внешний ключ которого я затем использую для заказа и т.д. Однако мне интересно, есть ли лучшая практика (с хорошей производительностью) или что другие люди используют для обработки такого рода ситуаций в коммерческом ПО?

PS: У меня также есть другие, немного более сложные ситуации, например, я хотел бы, чтобы данные для объекта User, прикрепленного к Order, изменялись по мере изменения пользователя, но никогда не удалялись. Ответ на вышеупомянутый вопрос определенно дал бы мне хорошую отправную точку.

Хотя трудно ответить на ваш вопрос, не видя, по крайней мере, вашего models.py, я предложу архивировать результаты. Вы можете добавить boolean field под названием historical, который по умолчанию будет False. Когда заказ сделан, вам нужно установить значение предыдущего заказа (или заказов) historical в True в вашем наборе представлений или функции. Здесь historical=True означает, что запись архивируется. Вы можете фильтровать по этому столбцу historical, чтобы отобразить то, что вам нужно. Извините, что это всего лишь высокоуровневый набросок.

Эта проблема изменения цен обычно решается в коммерческих приложениях на базе СУБД (SQL) путем выполнения двух действий.

  1. вставка строк в таблицу order_detail при оформлении заказа. Каждая строка этой таблицы содержит данные о проданном товаре: id товара, количество_товаров, цена_единицы, общая_цена, вес_единицы, общий_вес, налоговый_статус и так далее. Таким образом, приложение фиксирует, что именно было продано и по какой цене. Позднее изменение цены не испортит записи о продажах. Вы действительно должны сделать это.

  2. таблица price, содержащая item_id, цену, время начала_времени, время окончания_времени. Вы получаете текущую цену следующим образом:

    SELECT item.item, price.price
  FROM item
  JOIN price ON item.item = price.item
            AND price.start_date <= NOW()
            AND (price.end_date > NOW() OR price.end_date IS NULL)

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

Дело в том, что после принятия заказа его детали не могут измениться в будущем. Вы копируете фактические данные клиента (имя, адрес доставки и т.д.) в отдельную таблицу order из вашей текущей таблицы клиентов, когда вы принимаете заказ, и (как упоминалось выше) детали каждого товара в таблицу order_detail.

Ваши аудиторы будут ненавидеть вас, если вы этого не сделаете. Как-нибудь спросите меня, откуда я это знаю.

Вернуться на верх