Отслеживание изменений в базе данных SQL-сервера 2005

Я очень не хочу обойти проблему, и я знаю, что у Вас нет бюджета, но простое решение будет состоять в том, чтобы обновить до SQL Server 2008. Этому встроили эту функцию. Я думал, что это должно, по крайней мере, быть упомянуто для кого-либо еще, кто сталкивается с этим вопросом, даже если Вы не можете использовать его сами.

(Среди развертываемых выпусков SQL 2008 эта функция только доступна на Предприятии.)

Прежде всего во всех Ваших таблицах у Вас должны быть, по крайней мере, эти столбцы, добавленные к столбцам данных DateCreated, UserCreated, DateModified, UserModified. Возможно Вы могли бы хотеть добавить столбец "Status" или "LastAction" так, чтобы Вы на самом деле никогда не удаляли строку, Вы просто устанавливаете его на удаленное/вставленное/обновленное состояние. Затем Вы могли создать "Таблицу истории", которая является точной копией первой таблицы. Затем на любых обновлениях или удаляет, имеют триггерную копию Удаленные записи в таблице в Таблицу истории, изменяющую DateModified, UserModified и поля Status одновременно.

У меня была установка в SQL Server, где мы использовали бы представления для доступа к нашим данным, которые обработают, вставляет, обновляет и удаляет с триггерами INSTEAD OF.

Например: INSTEAD OF УДАЛЯЕТ, включают представление, отметил бы записи в базовой таблице, как удалено, и представление было фильтровано для не показа удаленных записей.

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

Представление должно быть связано со схемой, чтобы это работало.

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

Вот то, где это стало немного эксцентричным, хотя...

Для ВСТАВЛЯЕТ/ОБНОВЛЯЕТ, соответствующая строка (строки) были сохранены в таблице как данные XML, после того как ВСТАВЛЕНИЕ/ОБНОВЛЕНИЕ завершилось успешно. Для УДАЛЯЕТ, строка была сохранена до УДАЛИТЬ выполнения (хотя, реалистично, они, возможно, получили его от вывода Оператора удаления - по крайней мере, с SQL Server 2005).

Если я помню правильно, таблица только имела пару столбцов: UserID, DateTime входа, Тип Транзакции (I/U/D), данные XML, содержащие соответствующие строки, имя таблицы и значение первичного ключа (главным образом используемый для быстрого поиска какой записи, они хотели).

Много способов освежевать кошку, хотя...

Мой совет состоит в том, чтобы сохранить, просто. Разверните его позже, если/когда Вы должны.

Если у Вас есть способность сделать так, блокировка вниз пользователи, чтобы только смочь выполнить действенные операторы на таблицах с помощью хранимых процедур и затем обработать вход (однако, Вы хотите), оттуда.

мы создали наше собственное и просто нуждались в пользователе, и ПК передал в каждого, добавляет/обновляет хранимая процедура. затем это - просто вопрос получения исходной записи adn заполнение переменных и сравнение их к переданному в переменных и регистрации данных к нашей таблице. для удаляет, у нас просто есть копия инициирующих таблиц + поле метки времени, таким образом, запись действительно никогда не удаляется и может быть восстановлена каждый раз, когда нам нужно (очевидно, удалить плановые проверки для отношений FK и такого).

добавьте/обновите, что таблица журнала похожа на дату и время, table_name, column_name, record_id, old_value, new_value, user_id, компьютер

мы никогда не вставляем, аннулирует так, мы преобразовываем их в пустые строки, новые записи отмечены с '{новая запись}' в old_value столбце. record_id составлен из как много столбцов ключа для однозначного определения той единственной записи (field1 +'.' + field2 +...)