Trust me. Triggers in the DB world are not looked on as good practive. OK, from experience, knowledge and docs...
The code that is included inside an UPDATE trigger runs every time its related table is updated. In most UPDATE triggers, the code in the trigger affects only certain columns, not all of them. Because of this, it is pointless (and a waste of SQL Server resources) to run all of the code in the trigger if the column or columns you are interested in have not been updated. In other words, even if a column you are not interested in is updated, the UPDATE trigger will fire and run its code. To help reduce the unnecessary running of code in an UPDATE trigger, you can take advantage of one of two different functions: UPDATE() (available in SQL Server 2000) or COLUMNS_UPDATED() (available in SQL Server 7.0 and 2000). Either function can be used to test to see if a particular column you are interested in has changed or not. Because of this, you can write code in your trigger to only run if the column you are interested in has changed, otherwise you can prevent the code from running if the column you are interested in has not changed. This can reduce the amount of work the trigger needs to do, boosting overall performance of your database. The UPDATE() function is used to check only one column at a time. The COLUMNS_UPDATED() function can be used to check multiple columns at a time. If you must use triggers, keep em small. The amount of time that a trigger takes to run is mostly a function of the number of tables referenced in the trigger and the number of rows affected by the code inside the trigger. Because of this, always try to minimize the number of tables referenced in a trigger, and minimize the number of rows being affected. In addition, keep the code in your triggers to the very minimum to reduce overhead. This is important because triggers typically fire during INSERTs, UPDATEs, and DELETEs, all of which can be common occurrences in OLTP applications. The more code that runs in the trigger, the slower each INSERT, UPDATE, and DELETE that fires it will be. If you need to implement cascading referential integrity (such as cascading deletes) in your SQL 2000 databases, use the cascading referential integrity constraint instead of triggers to perform the cascading delete, as they are much more efficient and can boost performance. If you have an older (7.0 and older) application that you have moved to SQL Server 2000, and it used triggers to perform cascading deletes, consider removing the triggers and using cascading referential integrity instead. Don't use a trigger to enforce referential integrity if you have the option to use SQL Server's built-in referential integrity instead. Using SQL Server's built-in referential integrity is much faster than using a trigger to perform the same task. If you have a choice between using a trigger or a CHECK constraint to enforce rules or defaults within your SQL Server databases, you will generally want to choose a CHECK constraint as they are faster than using triggers when performing the same task. Try to avoid rolling back triggers because of the overhead involved. Instead of letting the trigger find a problem and rolling back a transaction, instead catch the error before it can get to the trigger (if possible based on your code). Catching an error early (before the trigger fires) consumes much fewer server resources than letting the trigger roll back. Just a few snippets. (<sic/>) -----Original Message----- From: Ken Ferguson [mailto:[EMAIL PROTECTED] Sent: 18 April 2005 15:13 To: CF-Talk Subject: RE: SQL Triggers (was Re: Last ID inserted) Just in case my thinking has been wrong for the last few years, how are triggers a performance drain??? If I can make one query to a database and then have the db handle some of the other operations I need to run, that sounds like a pretty efficient way to handle it to me. --Ferg -----Original Message----- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 7:54 AM To: CF-Talk Subject: RE: SQL Triggers (was Re: Last ID inserted) Well, for one they can be hard to track / find if you are not the developer and have sufficient rights to look at them, they are also a performance drain when simple constraint should be enough. Most cases which use a trigger now are unnecessary. -----Original Message----- From: C. Hatton Humphrey [mailto:[EMAIL PROTECTED] Sent: 18 April 2005 13:27 To: CF-Talk Subject: SQL Triggers (was Re: Last ID inserted) > Triggers...?! ;-) evil evil evil... Why do you say that? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:203235 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
