On Wed, Nov 3, 2010 at 9:26 AM, Gary Doades <[email protected]> wrote: > I'll agree with you to a large extent, complex business logic probably has > no place in the database, certainly not mine! However, many developers > (including me) use triggers and check constraints more to enforce integrity > than business logic. Primary/Foreign keys work in most cases, but there are > others where triggers are useful for enforcing integrity where there is no > direct primary/foreign key relationship. The application, IMO, is NOT the > place to enforce integrity. Certainly our databases are accessed by many > applications and utilities and integrity needs to be maintained in a common > and robust place, almost certainly the database. I would think (hope?) that > triggers are a little more widespread than you suggest.
I use insert triggers in a certain class of tables, and use disable_insert_output! on the corresponding models via a plugin that provides common application-level functionality for that class of tables. I would welcome a patch that detects an insert trigger and disables OUTPUT automatically. I realize there are other cases where OUTPUT can't be used, but it sounds like this is a case where OUTPUT is beneficial for 90% of the uses and 90% of the remaining 10% could be covered by checking for a trigger. SCOPE_IDENTITY is far from perfect either, BTW: http://stackoverflow.com/questions/908257/instead-of-trigger-in-sql-server-loses-scope-identity https://connect.microsoft.com/SQLServer/feedback/details/328811/scope-identity-sometimes-returns-incorrect-value -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
