Observers vs. Triggers

Question

What's the general consensus?

If you need to change the database after a given action, do you use an observer pattern and let the framework / application handle the update for you? Or do you bypass the application and delegate the update to a database trigger?

Obviously the trigger is faster, but is it worth it?

Answer 1

As we use LINQ2SQL this task is quite easy to be acoomplished overriding the SubmitChanges() method. Our main goal is to do auditing in our tables. The code would like this:

    /// <summary>
    /// Sends changes that were made to retrieved objects to the underlying database, 
    /// and specifies the action to be taken if the submission fails.
    /// NOTE: Handling this event to easily perform Audit tasks whenever a table gets updated.
    /// </summary>
    /// <param name="failureMode">The action to be taken if the submission fails. 
    /// Valid arguments are as follows:<see cref="F:System.Data.Linq.ConflictMode.FailOnFirstConflict"/>
    /// <see cref="F:System.Data.Linq.ConflictMode.ContinueOnConflict"/></param>
    public override void SubmitChanges(System.Data.Linq.ConflictMode failureMode)
    {
        //Updates
        for (int changeCounter = 0; changeCounter < this.GetChangeSet().Updates.Count; changeCounter++)
        {
            object modifiedEntity = this.GetChangeSet().Updates[changeCounter];
            SetAuditStamp(this, modifiedEntity, ChangeType.Update);
        }

        //Inserts
        for (int changeCounter = 0; changeCounter < this.GetChangeSet().Inserts.Count; changeCounter++)
        {
            object modifiedEntity = this.GetChangeSet().Inserts[changeCounter];
            SetAuditStamp(this, modifiedEntity, ChangeType.Insert);
        }
        base.SubmitChanges(failureMode);

We particulary don't like using triggers as they are always hidden into you DB and it makes hard to work out problems that may occur ... with having that into your code you just need to start debugging it to find out why something has failed for instance ...

Answer 2

I use triggers, but triggers are typically database-specific. If you plan on supporting multiple database servers, certainly find a way to cover it in code. If you're sure you'll be using a specific DB server, then your data-integrity will love you for your triggers.

Answer 3

Unless you are supporting multiple DBMSs, your framework is more likely to change in the next 5 years (say) than your choice of DBMS. Also, there could be requirements in the future to support other forms of input, e.g. web pages or mobile devices. Putting these actions into database triggers means the actions will be performed whatever the application that triggers them.