Как обрабатывать изменение количества запасов задним числом

Проблема

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

1. Inventory - это надежная, постоянная таблица фактов. Идея состоит в том, что в любой момент времени, если здание задымляется, таблица окончательно определяет положение запасов компании.

2. Таблица InventoryAdjustment - это просто транзакция с запасами компании, с таблицей Inventory. Его можно было назвать Transaction.

3. Столбец InventoryAdjustment.QoH - это дублированный столбец. QoH уже существует в Inventory. Когда вы создаете дублированный столбец, у вас есть:

   • нарушены правила нормализации (и, таким образом, у вас есть хорошо известная классическая ошибка, которую нам рекомендуется избегать и которая имеет последствия). Ваши таблицы больше не нормализованы, ваша база данных не является базой данных.

   • представил аномалию обновления. Это означает, что вам необходимо обновить данные (значение, которое является единственной версией истины) более чем в одном месте, в противном случае два (или более) элемента «рассинхронизируются». Идея в том, чтобы вообще не создавать дубликаты.

   • Если вы внедрили это для получения промежуточной суммы (InventoryAjustment.QoH, в последовательных строках), вы обманываете себя. Промежуточная сумма (Inventory.QoH плюс все корректировки до текущей строки) легко вводится в коде SQL. Попросите, если вам это нужно.

Теперь вы уже привыкли к такому ошибочному положению вещей, вы не рассматриваете его как ошибку, до сих пор оно «работало нормально». Поэтому вам может быть трудно признать, что это ошибка. Я оставлю это на ваше усмотрение.

• Ключевой термин - «до сих пор». Классически такие ошибки становятся проблемой только тогда, когда обнаруживается ошибка или когда пользователь хочет что-то изменить. Итак, во-первых, их нужно разоблачить и понять, что они из себя представляют.

• Событие только что произошло, вышеперечисленное сработало.

Решение

• Отбросьте столбец InventoryAdjustment.QoH.

• Сохраняйте повторный расчет и обновление столбца Inventory.QoH всякий раз, когда вставляется строка InventoryAdjustment.

• Теперь столбец Inventory.QoH является истинным , и это всегда верно. Он отражает точное QoH на складе прямо сейчас.

• Никакой "синхронизации" не требуется, потому что в файле нет двух версий правды или двух копий одной правды.

Конец истории.

Требование нового пользователя

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

• Теперь исправленная база данных прекрасно справляется с этим.

  • Обратите внимание, поскольку база данных была исправлена, есть только одно значение QoH. Если бы его не исправили, пришлось бы остановиться и спросить:

    <цитата>

    Какое значение QoH они хотят обновить: промежуточный, реальный или и то, и другое?
    Какой цели он служит?

• Приложение требует небольшой настройки. Я предполагаю, что текущая функция устанавливает InventoryAdjustment.Date на текущую дату перед вставкой.

  • Добавьте функцию, позволяющую привилегированному пользователю (например, которому было предоставлено разрешение "супервизор", чтобы разрешить это) set InventoryAdjustment.Date до действительной даты в прошлом, ограничивая ее на (например) 30 дней или что-то еще.

• Когда транзакция выполняется, она изменяет Inventory.QoH обычным способом.

Конец истории.

(Если это не так, это будет означать, что есть важные детали, которые не были сообщены. Пожалуйста, сделайте это.)

Пластырь Fix

Если вы не понимаете (а) характер ошибки и (б) правдивость исправления, т.е. вы счастливы сохранить его, тогда ...

Если бы это было разрешено, то каждую запись, которую я сделал в таблице INVENTORY_ADJUSTMENT в период с 1 марта по 10 апреля, также необходимо было бы обновить, поскольку каждая строка INVENTORY_ADJUSTMENT имеет поле QOH, которое теперь будет не синхронизировано. .

Да.

Это следствие аномалии обновления. Все повторяющиеся значения InventoryAdjustment.QoH для скорректированного элемента теперь в любом случае считаются ложными. Записывать их не было и не имеет смысла. Но вы их записали. И теперь их нужно обновить.

Код это.