But that is the whole point of a trigger!

To implement some feature that works transparent and automatic, on top of and without complicating, all those other things going on! For this you should love triggers that do not have unrelated side-effects. I do agree however to keep usage of triggers to what is absolutely nececary. If a feature can be done declarative or in a procedure where said transparancy is no requirement, go for that instead!

Unfortunatly since 2005 no trigger is guaranteed transparent due to the introduced output clause (bad implementation). Anyone using triggers to audit, log or debug using triggers for an application they do not know in full, might break the application doing so unknowingly!

The horror for me is to see everything (RI and interaction), wrapped in stored procedures as then the database is used as dumb storage (in an SQL way). With the same inflexibility and torrents of code that come with stuffing everything in a middle tier. Need to do some reporting...well, add yet anoter procedure. Need another filter parameter for some listview,...complicate things further in a procedure or add another specialised one. It is the path that never ends to generate more complexity and never leverages the concept of the relational database.