Комментарии 20
Делал что-то в этом духе только хранил посчитанную разницу между версиями.
Ничего похожего не нашел, решил поделиться.
Переименование таблицы/поля или изменение структуры таблиц (добавление полей, fk и др.) безвозвратно рушит ваше решение. Восстановить данные становится нетривиальной задачей
Json сложен (в PG 9.6) для обработки и поиска, а таблица "журнала" будет огромна.
Поделитесь, если возможно, практическим применением предложенного вами решения — количество записей, как решаете проблемы изменения схемы бд.
Осторожно, сейчас набегут любители orm и напишут, что "так неправильно и что вы будете делать, когда захотите сменить бд?")))))
В действительности мы у себя в работе такие темы используем часто для гарантированного логирования изменений любых апдейтах. Работает отлично!
Порядок количества записей, что делаете при изменении структуры бд?
Перекладывать же можно тупо через to_json(NEW) всего, что пришло, а можно умно в отдельную таблицу по нужным полям.
Как обычно каждый отдельный случай лучше отдельно рассматривать. Может вам пофиг и только для саппорта надо хоть в json хоть как показывать, тогда to_json зайдет, если нет — перекладываете в отдельную спец таблицу разбираясь с полями.
2. В коде триггера используется функция row_to_json, а тип поля jsonb, получаем ненужное преобразование из record -> json, а можно использовать функцию to_jsonb, которая сразу преобразует record -> jsonb. (jsonb может менять порядок ключей, поэтому json != jsonb)
3. Вместо row based триггера можно использовать statement триггер, там overhead-а может быть меньше, т.к. триггер будет запускаться 1 раз за statement, а не столько сколько строк изменилось.
4. Возможно правильнее использовать CLOCK_TIMESTAMP(), который будет показывать текущее время, а не зафиксированное в начале транзакции CURRENT_TIMESTAMP.
5.
Перед написанием статьи, искал в google на предмет возможного совмещения колес, педалей, рамы и руля.
Ничего похожего не нашел, решил поделиться.
pgconf.ru/2018/100615 с 25-го слайда начинается описание логирования, где история хранится в авто-партицированных таблицах.
5. По моей ссылке с полным примером, видно что PostgreSQL использовался 9.6.9, а «автопартицированные таблицы» появились только в 10 версии. Не знаю насколько хорошо, индексируются слайды pdf, может быть плохо искал.
2. Возможно
3. Записи историю которых предполагается сохранять, изменяются как правило по одной. В статье нет призывов сохранять версии абсолютно всех записей, базы данных.
4. В пунктах 2, 3 описаны примеры как избежать возможного overhead-a. А здесь похоже наоборот, почему?
5. По вашей ссылке, похожа только таблица версий, но она значительно сложнее.
На лавры изобретателя «версионирования записей» не претендую. В самом начале статьи описан вариант с XML, но там было много кода и несколько дополнительных запросов. Таблица можно сказать взята оттуда.
Это скорее лог чем версионность, версионность ИМХО это когда из таблицы можно достать запись из истории/текущую зная дату на которую нужна запись. Как в хранилищах, когда есть бизнес версионность и техническая одновременно (4 поля), дпугое дело что для oltp это скорее не нужно.
Пример простого версионирования записей PostgreSQL