LINUX.ORG.RU

[PostgreSQL] Хочу лог с историей.


0

0

Есть некоторые пользовательские функции, которые изменяют/удаляют/создают записи в таблице.

Я хочу иметь таблицу что-то вроде лога-истории, в которой будет храниться какую функцию я выполнил, и какое значение было до модицикации, если операция была «изменить».

В принципе более-менее понятно как это сделать для одной таблицы. (Объявить тип, ROW(...) и там хранить старое значение).

Но я хочу сделать подобное для разных таблиц. Т.е. типы старого значения будут разными.

Есть такое в pg?

По сути я хочу union как в Си.

Создай таблицу(-ы) с аналогичной структурой и храни записи целиком. С этим проще работать потом будет. Но места будет много занимать.

SOmni ★★ ()

это делается либо одним спец. триггером, который из системный таблиц считывает инфу об изменяемой таблице и ведет лог, либо триггеры генерсятся для таблицы спец.скриптом (или sql-процой)

один триггер на psql-ле не пишется, но в деталях я не помню почему :)

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

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

почитай например тут: http://www.postgresql.org/docs/8.3/static/ddl-partitioning.html

триггер и таблички можешь поискать на sql.ru, я его там выкладывал.

Rastafarra ★★★ ()

Такое логгирование на уровне таблиц базы данных - это очень плохая идея. Хотя бы плохая тем, что она не учитывает транзакционность, причём транзакционность не только на уровне БД - есть ещё и транзакци уровня приложения. Например, некая бизнес-операция может состоять из множества транзакций и единичных изменений записей в таблицах. В данном случае отдельно взятое изменение в конкретное таблице абсолютно ничего не расскажет про суть операции, а откат этого одного изменения приведёт к катострофическим последствиям.

Лучше всего начните понемного прорабатывать систему логгирования, но уже в самом приложении. Каждая часть Вашего проекта «знает», что она делает (какую историю использования реализовывает) и, соответственно, она может вполне «внятно» описать суть выполняемой бизнес-операции (будь то выписка счёта-фактуры, продажа товара и т.д.). И вот эти данные, необходимые для совершения операции (что за операция, информация по товару и т.д.), и нужно логгировать. В идеале должна получится система логгирования, которой бы передавались данные, достаточные для отката и/или повторного воспроизведения операции. Ну а сама система логгирования по логу выполненных операций должна всегда «знать», какой модуль приложения создал эту запись в логе, и какую функцию в этом модуле надо вызвать, чтобы откатить или повторно выполнить залоггированную бизнес-операцию.


Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

> Хотя бы плохая тем, что она не учитывает транзакционность, причём транзакционность не только на уровне БД - есть ещё и транзакци уровня приложения.

По существу согласен, но не понятно зачем как-то специфически учитывать транзакционность на уровне БД?

Eshkin_kot ★★ ()
Ответ на: комментарий от Eshkin_kot

> не понятно зачем как-то специфически учитывать транзакционность на уровне БД?

Транзакционность на уровне БД я привёл в качестве примера. Ну что мол, логгирование на уровне записи не расскажет в составе чего было изменение (в какой транзакции); соответственно, откат изменений по одной записи как бы «разрушит» ту транзакцию, в составе которой было изменение этой конкретной записи. Ну а потом я развил мысль о транзакциях уровня приложения.
Приношу извинения, если я ранее невнятно высказался.

Slavaz ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.