Вести журнал изменений данных пользователем в базе

[demav]

Есть задача: фиксировать кто, когда и что поменял в системе. Но что важно - с возможностью отката изменений.

СУБД: MS SQL Server 2008 R2

Кто какие инструменты или подходы применяет?

Я сам делал журнал изменений в таблицах на триггерах.

Но а) пока не делал откат (ведь данных много и они подчиненные) б) может уже появились новые технологии в 2008R2?

 

[demav]

Сам себе и отвечу.
Сделал так. Каждое изменение сохраняю триггером в одну таблицу.

Запись хранится в XML: SELECT * FROM inserted FOR XML AUTO, TYPE, ELEMENTS

В программе просмотра журнала уже анализирую XML и сравниваю что поменялось. Откат изменений еще не сделал, но полагаю, должно всё получится.

Единственное - база вырастет нереально. Может в другой базе хранить?

 

[sersin]

Создай таблицу атрибутов дай каждому ID И в лог пиши значения атрибутов. Если надо откатить бери значения старые на определенную дату

 

[Aristarh Dark]

ИМХО, выгоднее хранить "старые" значения записей, а не скрипты которыми записи были изменены.

 

[moldovanin]

Я бы еще и базу отдельную для лога сделал бы...а то размер возрастет очень быстро.

 

[maxim220]

Можно базу отдельную и не делать, а очень старые данные логов удалять

Добавлено через 9 минут

Есть задача: фиксировать кто, когда и что поменял в системе. Но что важно - с возможностью отката изменений.

СУБД: MS SQL Server 2008 R2

Кто какие инструменты или подходы применяет?

Я сам делал журнал изменений в таблицах на триггерах.

Но а) пока не делал откат (ведь данных много и они подчиненные) б) может уже появились новые технологии в 2008R2?

К сожалению, все не так просто получается в реальной жизни. Т.к. объект реальной жизни (у нас ведь объекты!) описывается более чем в 1 таблице (а бывает и в 5, и в 10, не всегда очеведно как он связаны), то , потратив некоторое время можно понять кто из пользователей что натворил. Но исправить, или вернуть "как было" практически никогда не возможно. Пишу это по опыту многолетней эксплуатации КИС - 200 таблиц, 30 млн записей, и .т.д. пользователй 100-150

Добавлено через 11 минут

Я бы еще и базу отдельную для лога сделал бы...а то размер возрастет очень быстро.

Можно и так. Но проблемы с работой с несколькими базами будут. Я бы не делал сейчас, когда памяти много, она дешевая, диски быстрые

 

[sikancil]

Можно базу отдельную и не делать, а очень старые данные логов удалять

Добавлено через 9 минут


К сожалению, все не так просто получается в реальной жизни. Т.к. объект реальной жизни (у нас ведь объекты!) описывается более чем в 1 таблице (а бывает и в 5, и в 10, не всегда очеведно как он связаны), то , потратив некоторое время можно понять кто из пользователей что натворил. Но исправить, или вернуть "как было" практически никогда не возможно. Пишу это по опыту многолетней эксплуатации КИС - 200 таблиц, 30 млн записей, и .т.д. пользователй 100-150

Добавлено через 11 минут

Можно и так. Но проблемы с работой с несколькими базами будут. Я бы не делал сейчас, когда памяти много, она дешевая, диски быстрые

Good to know.
Agreed! Sometimes users sucks the correct data.
**"Supporting them a lot are kindly HUGE TIME to spend."**
I'm doing to have data validations before them really put/post into DB.
And another way is to have them to make sure for the data before post and make sure your app/system with no bugs impact to data/DB.

When users do some mistakes, then show them for the log files not recording in DB and have them a punishment and reward $$$ to you for helping them updating the data.
** Prepare for much better documentations also for the app/systems. Let users learn this a lot before do their job.

 

[qpash]

В SQL 2012 все уже придумано

 

[SMA1971]

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