Коррекционный Update

В статье рассказывается о проблеме обновления данных в учётных системах и полезности учёта жизненного цикла сущностей и справочных значений.

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

К вам приходит бухгалтер и говорит, что сотрудница Иванова поменяла фамилию на Петрова. Вы заходите в справочник и меняете фамилию сотрудницы.

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

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

Еще через 3 месяца бухгалтер приходит опять и говорит, что у этой же сотрудницы ошибка в отчестве. Вы заходите в справочник, исправляете ошибку, и в результате порождается новая версия записи с правильным отчеством.

Бухгалтер звонит и жалуется, что в отчетах за предыдущие кварталы отчество сотрудницы выводится неправильно.

Тут приходит понимание, что в справочнике нужно сделать кнопку "Сохранить" немного сложнее. При нажатии кнопки необходимо спросить у пользователя, что, собственно, он хочет сделать, исправить ошибку или актуализировать значение?

Для правильного ведения учёта может потребоваться управление датами ввода в учёт (при создании записи) и вывода из учёта (при удалении записи).
» Например, ввод в группу нового участника и вывод из группы.

• Учёт требуется не только для сущностей, но и для справочных значений, участвующих в аналитике.
• Учёт содержит факты о жизненном цикле сущности/значения, а не записи в БД.
• Учётное версионирование не заменяет механизм логирования действий пользователей.
• Игнорирование учёта часто приводит к серьёзному ущербу для аналитики.

В реальности кейсы могут быть еще более запутанными, поэтому необходим UI для управления историческими версиями.

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

Кортежи actual_id + actual_from должны быть уникальными.

Если в отчетах нужно вывести актуальные значения, то JOIN делается к id, если нужно вывести исторические значения, то JOIN делается к actual_id с добавлением условия на срок актуальности. Примерно так …