Agreed Phil. At the enterprise level where you don't have control over all the software updating the database, triggers must be used for business rules enforcement.
For new development or enhancement to current software, use the OUTPUT clause where appropriate. It has the inserted/deleted tables like a trigger.
General note: What I noticed that database developers, especially novice, using triggers as swiss-army knife bandaid - "fix it all": poor table design, missing constraints, in fact poor application design.
There is no free-lunch with triggers, just like with indexes. They can be dropped unnoticed (unlike sprocs), they can have a negative impact on performance. They can also end in errors, which may not be easy to debug.
Kalman Toth, SQL Server & BI Training, SSAS, SSIS, SSRS; http://www.SQLUSA.com
For new development or enhancement to current software, use the OUTPUT clause where appropriate. It has the inserted/deleted tables like a trigger.
General note: What I noticed that database developers, especially novice, using triggers as swiss-army knife bandaid - "fix it all": poor table design, missing constraints, in fact poor application design.
There is no free-lunch with triggers, just like with indexes. They can be dropped unnoticed (unlike sprocs), they can have a negative impact on performance. They can also end in errors, which may not be easy to debug.
Kalman Toth, SQL Server & BI Training, SSAS, SSIS, SSRS; http://www.SQLUSA.com