Comments on: SQL Database Triggers http://thomaslarock.com/2009/03/sql-database-triggers/ World domination. Thu, 11 Mar 2010 23:30:49 -0500 http://wordpress.org/?v=2.9.2 hourly 1 By: Thomas LaRock http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-11660 Thomas LaRock Thu, 19 Nov 2009 03:17:01 +0000 http://sqlbatman.com/?p=1063#comment-11660 Thanks for your reply. You are right, it is not triggers that are bad per se. It is more about the fact that they are difficult to work with, especially with the graphical tools currently at our disposal. We were unit testing code and would not see expected results as a result of triggers that were being used to enforce business logic. triggers are often a hidden layer of code that can be difficult to think about when you are unit testing application code. i'm not sure that our triggers were badly written, or were ever the cause of a bug, and if that was the message you got from my blog post then I apologize for not being able to make things more clear the first time around. the point i wanted to make is that they can be a forgotten piece of logic when you are doing unit testing. you can decide for yourself about stored procedures. i happen to know a handful of people that would prefer to use nothing but dynamic SQL in web pages. everyone has their own comfort zone, i suppose. Thanks for your reply. You are right, it is not triggers that are bad per se. It is more about the fact that they are difficult to work with, especially with the graphical tools currently at our disposal.

We were unit testing code and would not see expected results as a result of triggers that were being used to enforce business logic. triggers are often a hidden layer of code that can be difficult to think about when you are unit testing application code.

i’m not sure that our triggers were badly written, or were ever the cause of a bug, and if that was the message you got from my blog post then I apologize for not being able to make things more clear the first time around. the point i wanted to make is that they can be a forgotten piece of logic when you are doing unit testing.

you can decide for yourself about stored procedures. i happen to know a handful of people that would prefer to use nothing but dynamic SQL in web pages. everyone has their own comfort zone, i suppose.

]]> By: sqlblindman http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-11651 sqlblindman Wed, 18 Nov 2009 17:39:03 +0000 http://sqlbatman.com/?p=1063#comment-11651 The fact that you and your former colleagues did not know how to properly write or use triggers does not mean triggers are bad. If you were using triggers to enforce referential integrity that indicates a fault in either your database design or your architecture. Quit blaming the tool. The fact that triggers were "always the last thing we would think about" when tracking bugs indicates just how rarely triggers were the cause of your bugs. I find more bugs in stored procedures than triggers. Should we stop using those as well? The fact that you and your former colleagues did not know how to properly write or use triggers does not mean triggers are bad. If you were using triggers to enforce referential integrity that indicates a fault in either your database design or your architecture. Quit blaming the tool.

The fact that triggers were “always the last thing we would think about” when tracking bugs indicates just how rarely triggers were the cause of your bugs.

I find more bugs in stored procedures than triggers. Should we stop using those as well?

]]> By: Turn Off NOCOUNT | SQLBatman.com http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1504 Turn Off NOCOUNT | SQLBatman.com Tue, 17 Mar 2009 20:16:01 +0000 http://sqlbatman.com/?p=1063#comment-1504 [...] boost performance with triggers, so perhaps that is at play here as well. But since we already know how I feel about triggers, I will not accept that as a valid reason for this instance wide configuration option. I would much [...] [...] boost performance with triggers, so perhaps that is at play here as well. But since we already know how I feel about triggers, I will not accept that as a valid reason for this instance wide configuration option. I would much [...]

]]> By: SQLBatman http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1260 SQLBatman Thu, 05 Mar 2009 14:05:24 +0000 http://sqlbatman.com/?p=1063#comment-1260 That is similar to some of the workarounds I have seen (or done) in the past in order to help troubleshoot data issues. That is similar to some of the workarounds I have seen (or done) in the past in order to help troubleshoot data issues.

]]> By: Matt Dragon http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1259 Matt Dragon Thu, 05 Mar 2009 13:30:35 +0000 http://sqlbatman.com/?p=1063#comment-1259 We've actually started to move to having Triggers use their own UserID when making changes to data. Our database already has Last Change and Creation tracking columns, as well as audit tables (the only valid reason I've ever really seen for using triggers). If a trigger blames its change on User A you have no way of knowing what really caused the data to change. However, if the trigger blames itself you can always back track to the real change that fired the trigger. We’ve actually started to move to having Triggers use their own UserID when making changes to data. Our database already has Last Change and Creation tracking columns, as well as audit tables (the only valid reason I’ve ever really seen for using triggers). If a trigger blames its change on User A you have no way of knowing what really caused the data to change. However, if the trigger blames itself you can always back track to the real change that fired the trigger.

]]> By: Why Are You Surprised? | SQLBatman.com http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1239 Why Are You Surprised? | SQLBatman.com Wed, 04 Mar 2009 16:01:26 +0000 http://sqlbatman.com/?p=1063#comment-1239 [...] Or designed a database one way only to realize that there was a better, simpler design, one free of triggers and [...] [...] Or designed a database one way only to realize that there was a better, simpler design, one free of triggers and [...]

]]> By: SQL Server and NULL Values | SQLBatman.com http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1225 SQL Server and NULL Values | SQLBatman.com Tue, 03 Mar 2009 19:36:37 +0000 http://sqlbatman.com/?p=1063#comment-1225 [...] seemed to have struck a minor chord with my hatred for database triggers. I had very few comments, but a handful of emails and exchanged even more tweets on the subject. [...] [...] seemed to have struck a minor chord with my hatred for database triggers. I had very few comments, but a handful of emails and exchanged even more tweets on the subject. [...]

]]> By: Meeting Minutes for Trigger Design | Brent Ozar - SQL Server DBA http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1219 Meeting Minutes for Trigger Design | Brent Ozar - SQL Server DBA Tue, 03 Mar 2009 13:12:44 +0000 http://sqlbatman.com/?p=1063#comment-1219 [...] wrote recently about how database triggers suck.  It’s pretty funny, and it made me stop to think.  What would it have been like to sit in [...] [...] wrote recently about how database triggers suck.  It’s pretty funny, and it made me stop to think.  What would it have been like to sit in [...]

]]> By: Matt http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1200 Matt Mon, 02 Mar 2009 17:43:37 +0000 http://sqlbatman.com/?p=1063#comment-1200 Amen brother! Amen brother!

]]> By: K. Brian Kelley http://thomaslarock.com/2009/03/sql-database-triggers/comment-page-1/#comment-1199 K. Brian Kelley Mon, 02 Mar 2009 14:11:51 +0000 http://sqlbatman.com/?p=1063#comment-1199 Triggers are great for writing articles about (having done that). They are also great for retrofitting a database with auditing when you have to have auditing and you can't (aren't allowed) to make any other changes and you aren't allowed (can't afford) to purchase another tool for the same purpose. But in this case you accept the trade-off of the problems you've mentioned above in order to get the auditing you want. Otherwise, I've advised to my developers that if you want that kind of auditing, etc., build it in the stored procedures or into the application logic so it's visible when troubleshooting, as you've mentioned. But you need to write that post on NULLs. Triggers are great for writing articles about (having done that). They are also great for retrofitting a database with auditing when you have to have auditing and you can’t (aren’t allowed) to make any other changes and you aren’t allowed (can’t afford) to purchase another tool for the same purpose. But in this case you accept the trade-off of the problems you’ve mentioned above in order to get the auditing you want.

Otherwise, I’ve advised to my developers that if you want that kind of auditing, etc., build it in the stored procedures or into the application logic so it’s visible when troubleshooting, as you’ve mentioned.

But you need to write that post on NULLs.

]]>