Практика ведения историчных таблиц в web приложении
Всем привет!
Разрабатываю web-приложения на Django. Заказчик хочет вести историю изменения таблиц в отдельных таблицах с постфиксом _HIST. Допустим есть таблица CARS с полями CAR_ID, CAR_NAME. Допустим в ней была запись:
CAR_ID = 1, CAR_NAME = 'BMW'
. На запись сделали DELETE where CAR_ID = 1. И в _HIST должна появиться запись:
CAR_ID = 1, CAR_NAME = 'BMW', EFF_FROM_DT = 1900-01-01, EFF_TO_DT = current_date
.
Планирую реализовать это через триггеры Postgres.
Вопрос: Раньше в приложениях не видел практики ведения таких таблиц, может есть какие-то глобальные причины использования такого подхода?
Ответы (1 шт):
Вполне нормальная практика, для БД, имеющих хоть какое-то отношение к деньгам или прочим видам строгой отчётности.
Например, если вы осуществляете продажи, вы обязаны несколько лет (3 или 5, точно не помню), хранить у себя исходящие документы. Достаточно важно, чтоб в случае чего вы могли восстановить названия товаров именно в том виде, в котором отдали клиенту на бумаге.
Если всю историю хранить в одной таблице, то выборка актуальных значений со временем будет замедляться, и это плохо.
Тут есть несколько слегка различающихся подходов к организации именно HIST-таблицы, но общая идея одна. В основной таблице только актуальные данные, а прежние можно вытянуть из HIST