Как отслеживать изменения данных в таблице базы данных

Question

Каков наилучший способ отслеживания изменений в таблице базы данных?

Представьте, что вы получили приложение, в котором пользователи (в контексте приложения, а не пользователи БД) могут изменять данные, которые хранятся в некоторой таблице базы данных. Каков наилучший способ отслеживания истории всех изменений, чтобы вы могли показать, какому пользователю и в какое время изменять какие данные, как?

Answer 1

Один из методов, которые я видел довольно часто, - это иметь таблицы аудита. Затем вы можете показать только то, что изменилось, что изменилось и из чего оно изменилось, или все, что душе угодно :) Затем вы могли бы написать триггер для фактической регистрации. Не слишком больно, если все сделано правильно ...

Независимо от того, как вы это делаете, это зависит от того, как ваши пользователи подключаются к базе данных. Используют ли они одного пользователя приложения через контекст безопасности в приложении, подключаются ли они, используя свои собственные учетные записи в домене, или приложение просто подключает всех с общей учетной записью sql?

Если вы не можете получить информацию о пользователе из соединения с базой данных, это немного больше боли. И затем вы можете посмотреть на ведение журналов в приложении, поэтому, если у вас есть процесс с именем «CreateOrder» или что-то еще, вы можете войти в таблицу Order_Audit или что-то еще.

Выполнение всего этого внутри приложения открывает немного больше возможностей для изменений, внесенных извне приложения, но если у вас есть несколько приложений, использующих одни и те же данные, и вы просто хотели увидеть, какие изменения были внесены вашими, возможно, это что ты хотел ... <<em> пожимает плечами >

Удачи тебе, хотя!

- Кевин

Answer 2

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

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

Имейте в виду, что регистрация изменений в базе данных создаст много данных и замедлит работу системы. Может быть целесообразно использовать решение для очереди сообщений и отдельную базу данных для ведения журнала аудита, в зависимости от размера приложения.

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

Answer 3

Исследуя этот же вопрос, я нашел обсуждение здесь очень полезным. Он предлагает установить параллельную таблицу для отслеживания изменений, где каждая таблица отслеживания изменений имеет те же столбцы, что и отслеживаемые, плюс столбцы для того, кто ее изменил, когда и если он был удален. (Должна быть возможность генерировать схему для этого более или менее автоматически с использованием переэкспонированной версии ваших ранее существующих сценариев.)

Answer 4

У вас есть несколько вопросов, которые не очень хорошо связаны друг с другом.

На базовом уровне базы данных вы можете отслеживать изменения, имея отдельную таблицу, в которую добавляется запись с помощью триггеров в операторах INSERT / UPDATE / DELETE. Это общий способ отслеживания изменений в таблице базы данных.

Другая вещь, которую вы хотите, это знать, какой пользователь внес изменения. Обычно ваши триггеры этого не знают. Я предполагаю, что если вы хотите знать, какой пользователь изменил часть данных, то возможно, что несколько пользователей могут изменить одни и те же данные.

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

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

Answer 5

Предположим, у меня есть таблица Person с 10 столбцами, которые включают PersonSid и UpdateDate. Теперь я хочу отслеживать любые обновления в Персональной таблице. Вот простая техника, которую я использовал:

1. Создание таблицы person_log

   создать таблицу person_log (дата datetime2, sid int);

2. Создать триггер для таблицы Person, который будет вставлять строку в таблицу person_log при каждом обновлении таблицы Person:

   создать триггер tr в dbo.Person
   для обновления
   как вставить в person_log (date, sid) выбрать обновленный DTM, PersonSID из вставленного

После любых обновлений запросите таблицу person_log, и вы сможете увидеть обновленный personSid. То же самое вы можете сделать для вставки, удаления.

Выше приведен пример для SQL, дайте мне знать в случае каких-либо запросов или используйте эту ссылку: http://www.4guysfromrolla.com/webtech/042507-1.shtml

Answer 6

Если все меняется с php. Вы можете использовать class для входа в систему INSERT / UPDATE / DELETE перед запросом. Это будет сохранение действие , таблица , столбец , newValue , oldValue , дата , система (при необходимости), ip , UserAgent , clumnReference , operatorReference , valueReference . Все таблицы / столбцы / действия, которые должны регистрироваться, являются настраиваемыми.

Answer 7

Давайте попробуем с этим компонентом с открытым исходным кодом:

https://tabledependency.codeplex.com/

TableDependency - это общий компонент C #, используемый для получения уведомлений при изменении содержимого указанной таблицы базы данных.

Answer 8

Журнал трассировки в отдельной таблице (со столбцом идентификаторов, возможно, с временными метками)?

Собираетесь ли вы также отменить изменения - возможно, предварительно создать оператор отмены (DELETE для каждого INSERT, (не) UPDATE для каждого обычного UPDATE) и сохранить его в трассировке?