Pros and Cons of Triggers vs. Stored Procedures for Denormalization

Question

When it comes to denormalizing data in a transactional database for performance, there are (at least) three different approaches:

1. Push updates through stored pr

Answer 1

Triggers are useful where you multiple update paths on a table.

We use stored procs and have about 4 paths at least (Add, Update, Deactivate, Copy)

It's easier to work with the data we've just inserted/updated in a trigger no matter what action we do or how many rows we affect.

A stored proc works for a single update path only I feel: unless you want to repeat code...

Now, TRY/CATCH in triggers means correct, predictable error handling: triggers on SQL Server 2000 and earlier caused batch aborts on error/rollback which is not ideal (to say the least!). So, triggers are more reliable now anyway.

Answer 2

It depends on your business requirements and how your database is used. For instance, suppose there are many applications and many imports that affect the table (we have hundreds of things that can affect our tables) . Suppose also there is occasionally the need to write queries that are run from SSMS (yes even on prod) to do things like update all prices by 10%. If you do these types of things then a stored proc is impractical, you will never have every possible way to affect the database covered.

If this data change is necessary to data integrity or many applications or processes (imports, SQL Server Jobs, etc.) can affect data, then it belongs in the trigger.

If the data change is needed only sometimes or you have total control of how data is changed from only one application, then a stored proc is fine.

Answer 3

Triggers are automatic Side Effects and will almost certainly bite you down the line when you want to do something and can't because of the side effects of the triggers. Mainly things like having your system participate in some XA Transaction with other external systems. Triggers make this IMPOSSIBLE. Also it is Side Effect logic that can ONLY be activated by doing the Trigger activator again. If you want to recreate data in the Warehouse you can't just run some procedure and recreate it, you have to execute all the activities that will fire the Triggers, this is a nightmare. INSERTS, UPDATES and DELETES should be idempotent and orthogonal. Triggers needlessly complicate workflows, even if you think they are simplifying them they aren't.