Записывать изменения, внесенные во все поля таблицы, в другую таблицу (SQL Server 2005)

Question

Я бы хотел внести изменения, внесенные во все поля таблицы, в другую таблицу. Это будет использоваться для ведения истории всех изменений, внесенных в эту таблицу (Ваша основная таблица журнала изменений).

Каков наилучший способ сделать это в SQL Server 2005?

Я предполагаю, что логика будет помещена в некоторые триггеры.

Каков хороший способ пройти по всем полям, проверяя наличие изменений, без жесткого кодирования всех полей?

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

Я заметил, что в SQL Server 2008 появилась новая функция, называемая Change Data Capture (CDC). (Вот хорошее видео Channel9 на CDC). Это похоже на то, что мы ищем, за исключением того, что мы используем SQL Server 2005, уже располагаем макетом таблицы журналов и также ведем журнал пользователя, который внес изменения. Мне также трудно оправдать написание до и после изображения всей записи, когда одно поле может измениться.

Наша текущая структура файла журнала имеет столбец для Имя поля, Старые данные, Новые данные.

Заранее спасибо и хорошего дня.

Обновлено 22.12.08: Я провел еще одно исследование и нашел эти два ответа на Live Search QnA

1. Вы можете создать триггер для этого. Увидеть Как проверить изменения данных сервера sq l .

2. Вы можете использовать триггеры для регистрации изменений данных в таблицах журналов. Вы также можете приобрести Log Explorer у www.lumigent.com и использовать его для чтения журнала транзакций, чтобы узнать, какой пользователь внес изменения. Однако для этой опции база данных должна быть полностью восстановлена.

Обновление от 23.12.08: Я также хотел получить простой способ сравнить то, что изменилось, и это выглядело как обратная сторона PIVOT, который я обнаружил в SQL, называется UNPIVOT. Сейчас я склоняюсь к триггеру, использующему UNPIVOT для таблиц INSERTED и DELETED. Мне было любопытно, если это уже было сделано, поэтому я пытаюсь выполнить поиск по запросу " unpivot Удалено вставлено ".

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

Answer 1

Довольно поздно, но, надеюсь, это будет полезно для других читателей ...

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

Короткий ответ: нет «правильного» решения, которое бы подходило всем. Это зависит от требований и проверяемой системы.

Триггеры

• Преимущества : относительно прост в реализации, большая гибкость в отношении того, что проверяется и как хранятся данные аудита, потому что у вас есть полный контроль
• Недостатки : Это становится грязно, когда у вас много столов и еще больше триггеров. Техническое обслуживание может стать тяжелым, если нет какого-либо стороннего инструмента, чтобы помочь. Кроме того, в зависимости от базы данных это может повлиять на производительность.

Создание триггеров аудита в SQL Server
Записать изменения в таблицу базы данных с помощью триггера

CDC

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

Чтение журнала транзакций

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

Чтение файла журнала (* .LDF) в SQL Server 2008
Проводник / анализатор журнала транзакций SQL Server

Сторонние инструменты

Я работал с несколькими инструментами аудита от ApexSQL, но есть также хорошие инструменты от Idera (менеджер соответствия) и Программное обеспечение Krell (всенаправленный аудит)

ApexSQL Audit - Инструмент аудита на основе триггеров. Создано и управляет триггерами аудита

ApexSQL Log - позволяет проводить аудит путем чтения журнала транзакций

Answer 2

В SQL '05 вам на самом деле не нужно использовать триггеры. Просто взгляните на предложение OUTPUT. OUTPUT работает со вставками, обновлениями и удалениями.

Например:

INSERT INTO mytable(description, phone)
OUTPUT INSERTED.description, INSERTED.phone INTO #TempTable
VALUES('blah', '1231231234')

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

Как примечание, это чрезвычайно простой способ получения значения поля идентичности.

Answer 3

Вы можете использовать Log Rescue . Это почти так же, как Log Explorer, но это бесплатно.

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

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