Возможность запуска SQLCLR или хранимой процедуры аудита? - PullRequest
Новая
       12

Возможность запуска SQLCLR или хранимой процедуры аудита?

1 голос
/ 15 ноября 2011

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

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

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

  • Метка времени (datetime) - когда произошло изменение?
  • Имя пользователя (varchar) - кто внес изменение?
  • AfferedTableName (varchar) - какая таблица была затронута?
  • ActedRowKey (varchar) - это будет простой или составной ключ, например (Id=42, A=4,B=2)
  • OperationType (char(1)) - либо I, U или D для вставки, обновления и удаления соответственно.
  • InsertedXml (xml) - сериализованная строка xml (SELECT * FROM INSERTED FOR XML AUTO)
  • DeletedXml (xml) - строка, сериализованная в xml (SELECT * FROM DELETED FOR XML AUTO)

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

  • Реализуйте это полностью как метод SqlTrigger:
  • Реализуйте это как метод SqlProcedure с параметрами:
    • SchemaName
    • TABLENAME
  • deletedXml

Буду признателен за любую конструктивную критику и предложения. Мое ограничение заключается в том, что я должен осуществлять аудит на уровне базы данных с использованием триггеров, и я хочу, чтобы он был максимально поддерживаемым (читай: сменным и заменяемым), насколько это возможно. Также, в идеале, я не хочу иметь сотни триггеров с одинаковым телом на случай, если мне придется их модифицировать.

Ответы [ 2 ]

2 голосов
/ 23 октября 2012

Существует серьезное ограничение в триггерах SQLCLR, которое не позволит вам реализовать триггеры аудита в SQLCLR: вы не можете найти родительский объект, который был изменен изнутри триггера SQLCLR. т.е. если у вас есть одна подпрограмма триггера SQLCLR, зарегистрированная в нескольких таблицах, вы не можете найти, из какой таблицы была обновлена ​​/ вставлена ​​/ удалена. На первый взгляд @@ procID может показаться полезным, однако при вызове изнутри триггера SQLCLR @@ procid возвращает одно и то же значение, независимо от того, какая таблица была затронута. Я искал в Интернете и много экспериментировал, и я не нашел решения. Я нашел больше людей, имеющих такую ​​же проблему. Некоторые сообщения датируются 2006 годом.

Я создал запрос функции с Microsoft на Microsoft Connect. Пожалуйста, войдите в систему и нажмите стрелку ВВЕРХ, чтобы реализовать его, чтобы вы могли использовать триггер SQLCLR для своих целей: https://connect.microsoft.com/SQLServer/feedback/details/768358/a-sqlclr-trigger-should-be-given-the-parent-object-in-the-sqltriggercontext

1 голос
/ 15 ноября 2011

Я уже некоторое время использую вариант этого скрипта для создания триггеров аудита из некоторых моих проектов с отличными результатами:

http://www.simple -talk.com / sql / database-управления / поп-rivetts-SQL-сервер-чаво-No.5-поп-на-аудит-трейл /

...