SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Trigger Notes

One of the questions that came up during a panel discussion at SQLSaturday #4 was whether it was better to have one trigger or many. It's a Zen question, no real right answer as far as I'm concerned. In practice having 7 update triggers is probably not a good idea, both from a raw performance perspective as well as just being able to easily see what is going on. I like having separate triggers for insert, update, delete, though I sometimes combine them for basic auditing. I also like adding an additional trigger when I'm adding functionality that probalbly won't be permanent, when I'm done I can just drop the trigger with no danger I've made an incorrect edit to the existing trigger.

Another question was about auditing within triggers and making sure they get a true picture of the original state of the data. The deleted table holds the 'before' image of the data and that stays static for the life of the trigger. It doesn't matter if you read from it as the first line of the trigger or the last, it's still the before image.

The last question was about logging changes in column format, showing before/after value along with the column name. Totally valid and possibly lighter than my standard approach of just preserving a copy of the entire row. The only thing I'd argue for is a standard implementation so you don't get a mish mash that makes trying to use/report on the auditing data painful.


I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.


No comments.

Leave a Comment

Please register or log in to leave a comment.