spaghettidba (10/14/2016)
Generally speaking, triggers are a very bad place to implement business logic, because they make the code difficult to debug/follow. They are some sort of "hidden" code that is executed even in situations when you would like them to be skipped.
Implementing your business logic in "explicit" code (say stored procedures or your favourite programming language) is a better practice.
Triggers are usually a "last resort" when changing everything else is impossible (third party code) or too expensive.
As a DBA (rather than a developer), I deeply disagree. Logic like that should be put where it always runs and it always runs the same way. That's perfect for a trigger. There may be thirty ways to add or remove data, but I want a single, consistent method for calculating totals based on that data.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.