Do arguments put forward for avoiding the use of triggers hold true for ISV products?

I've read the various accounts / opinions on the use of triggers here and elsewhere on the web and am trying to be careful not to create a duplicate question here.

Much of the reasoning put forward against the use of triggers is the unknown, unseen side effects they may have for others interacting with the data. It seems to me that this would be more prevalent in an enterprise scenario where many departments may hang various applications off a company's database and unseen business rules of one department should not be hidden in triggers which could affect others or become outdated.

I am bu开发者_StackOverflowilding a product which incorporates an accounting system. I am finding a combination of triggers and computed fields very useful for maintaining fields such as invoice totals (including and excluding gst) statuses of transactions (like invoice partly paid, fully paid, partly authorised for payment and so on).

I have justified the use of some very specific (atomic) triggers to enforce the most general of accounting rules, on the grounds that the "business" logic they enforce isn't really business logic but data integrity which will ease some reporting requirement for us or third parties in the future and that our database must survive in the wild with all manner of qualified (or not) "I.T. support" poking around at it. Our average user doesn't really understand the architecture or nature of a computer system and would naively trust anyone to help them with their computer system, based on their ability to turn on the computer or surf the web.

I don't want, for example, an invoice status to be broken because some unknown "I.T. guru" or business owner's nephew, thinks he needs to delete a few rows from a table or change a payment amount manually.

Do you think the generally accepted aversion to the use of triggers is more prevalent in an enterprise scenario or is it every bit as relevant to ISVs shipping a database with their product?

It depends. When used in a database application or RDBMS supported client-server or n-tier application for something like logging actions on a table, I have found triggers useful in both an enterprise and ISV scenario.

I would avoid using them in transactions or to implement business logic as they invariably complicate any issues in your app which might be affected (as it is easy to forget they are there or overlook their side effects)

Also, some MPP databases, such as EMC Greenplum, do not allow user defined triggers, so if your app may ever need to scale-out this will also complicate matters.

The general aversion you speak of is based on the issues they can present and these are valid concerns regardless of whether you are writing enterprise software or if you are an ISV