Возникла необходимость вести аудит изменения данных в существующей системе.
Требования:
Простота подключения/отключения логгирования отдельных таблиц.
Сократить до минимума изменения в уже существующих функциях БД.
Минимизировать деградацию производительности.
Первая мысль была добавить в логгируемые таблицы поля _user, _create_date, _delete_date.
На операцииаудит postgresql INSERT, UPDATE, DELETE повесить триггеры, работающие с этими полями.
При добавлении записи заполнять поля _user и _create_date.
Вместо обновления делать копию обновляемой строки (с измененными значениями), а в самой обновляемой строке заполнять поле _delete_date.
Вместо удаления записи заполнять поле _delete_date.
При обращении к такой таблице в блок WHERE необходимо добавлять _delete_date IS NULL.
Этот механизм мог бы сработать, если бы был заложен в архитектуру БД изначально, но у нас к моменту внедрения логгирования было написано более 3000 функций, в каждую из которых пришлось бы вносить изменения.
Затем появилась идея хранить логи отдельно от данных. Идея заключалась в следующем:
В схеме logs создается копия структуры таблицы плюс несколько служебных полей.
На каждую логгируемую таблицу вешается триггер, который выполняет всю грязную работу по сохранению изменившихся данных.
