MS SQL Server: универсальный Logger сделанный как триггер

[Glen]

MS SQL Server 2008

Вот на http://www.softcodearticle.com/2012/...in-sql-server/ нашёл пример - универсальный код триггера, позволяющий регистрировать операции INSERT, UPDATE и DELETE на любой таблиц. Этот триггер регистрирует их в таблице такого вот типа:

CREATE TABLE [dbo].[Audit](
[TYPE] [CHAR](1) NULL,
[TableName] [VARCHAR](128) NULL,
[PK] [VARCHAR](1000) NULL,
[FieldName] [VARCHAR](128) NULL,
[OldValue] [VARCHAR](1000) NULL,
[NewValue] [VARCHAR](1000) NULL,
[UpdateDate] [datetime] NULL,
[UserName] [VARCHAR](128) NULL
) ON [PRIMARY]

Проверил его работу - вроде как всё в порядке.
Но так как я никогда триггеров раньше не писал, то "терзают смутные сомненья" - вдруг в нём какой-то баг которого я пока не замечаю.

Никто не видит никаких потенциальных проблем в том триггере?

[ReportCube]

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

[Аватар]

Если еще его повесить на каждую таблицу достаточно серьёзнной базы, то приличная часть мощностей сервера уйдет на логирование. Не исключаю жутких тормозов при интенсивном обновлении данных. Это конечно проверить нужно, в любом случае согласен с ReportCube - информационной пользы будет не намного больше, чем при избирательном логировании

[Glen]

Сообщение от ReportCube

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

конкретно в МОЕЙ задаче Заказчик уже выделил несколько таблиц подлежащих Логированию. И информация в Логе ему нужна как раз такая которую обеспечивает этот Пример. Так что с этой стороны у меня всё в порядке...

Меня больше интересовало - не просмотрел ли я какой БАГ в том коде? Код взят не с "официального" сайта а просот с блога какого-то программиста.

Сообщение от Аватар

Если еще его повесить на каждую таблицу достаточно серьёзнной базы, то приличная часть мощностей сервера уйдет на логирование. Не исключаю жутких тормозов при интенсивном обновлении данных. Это конечно проверить нужно, в любом случае согласен с ReportCube - информационной пользы будет не намного больше, чем при избирательном логировании

Сообщение от ReportCube

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

конкретно в МОЕЙ задаче Заказчик уже выделил несколько таблиц подлежащих Логированию. На них и только на них я и повешу этот Триггер. То есть это не значит что раз он generic я его буду вешать на ВСЕ таблицы в моей базе :-)

И информация в Логе моему Заказчику нужна как раз такая которую обеспечивает этот Пример. Так что с этой стороны у меня всё в порядке...

Меня больше интересовало - не просмотрел ли я какой БАГ в том коде? Код взят не с "официального" сайта а просто с блога какого-то программиста.

Сообщение от ReportCube

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

Кстати, что касается "универсальности" этого кода:

можно вынести в отдельную процедуру тот код который формирует переменную @SQL. То есть - почти всё начиная от "SELECT @UserName = system_user..." и до момента когда она полностью сформирована. А это - бОльшая и самая сложная часть кода.

Вот уже выполнять выражение @SQL придётся в самом триггере - потому что только там доступны эти "таблицы" Inserted и Deleted. Правильно я рассуждаю?

[Аватар]

А что даст выделение части кода в процедуру? Только замедлит выполнение с учетом того, что EXEC в цикле выполняется. А в самом @SQL ссылок на Inserted и Deleted нет, обращение идет к временными таблицами #ins и #del

[Glen]

Сообщение от Аватар

А что даст выделение части кода в процедуру? Только замедлит выполнение с учетом того, что EXEC в цикле выполняется. А в самом @SQL ссылок на Inserted и Deleted нет, обращение идет к временными таблицами #ins и #del

>А что даст выделение части кода в процедуру? - это будет общая часть для ВСЕХ триггеров, которую не надо будет копировать в каждый триггер.

"А в самом @SQL ссылок на Inserted и Deleted нет, обращение идет к временными таблицами #ins и #del" - да, но: эти таблицы имеют каждая свой тип. Потому - как я понимаю - нельзя написать процедуру которая бы их принимала как аршументы (если бы мы хотели в эту "универсуальную процедуру" затолкать вообще всё). Так?

[Аватар]

Как минимум до MS SQL 2005 включительно таблицу параметром типа Table в хранимку передать нельзя. Для более поздних версий нужно посмотреть. И для сведения - EXEC (@S) очень тормозная штучка

[Glen]

Сообщение от Аватар

Как минимум до MS SQL 2005 включительно таблицу параметром типа Table в хранимку передать нельзя. Для более поздних версий нужно посмотреть.

Да, в 2008 можно. НО: ведь если мы захотим написать универсальную процедуру, то как же мы сможем определить тип этих табличных параметров? Ведь в T-SQL нет параметра с типом "таблица вообще"; таблица должна быть определённого типа....

[Аватар]

Да нет необходимости #ins и #del передавать как параметры. В хранимке вызванной из триггера, в котором эти таблицы созданы, они и так будут доступны по своим именам. Собственно автор для того их и создал, чтобы по именам использовать в EXEC (), что эквивалентно вызову хранимки, пусть и системной