Triggers appears just like a simple solution for Audit logging. Why must I personally use Interceptors?

  1. Database portability is a disadvantage of trigger...

what exactly are others?

Disadvantage of utilizing anything except a trigger isn't that all data changes may occur with the GUI and for that reason may not get drenched. You need to take into account that databases are transformed from many sources including data imports and hang-based queries in the query window (for example when someone is requested to update all prices by 10%). If you are using permanently, you ought to make certain it captures in whatever way data could be transformed. If you are using dynamic sql whatsoever, then all of your tables are available to the customers to create changes directly within the database including fradulaent changes made to steal from the organization. Customers carrying out fraud are among the key things audit triggers are made to catch. If you feel your audit option would be ok becasue it captures evreything in the interface which everything it must capture, you're very, very wrong. I'm not sure how interceptors work, however, you ought to test with SSIS (or DTS) imports and queries in the query window before you decide to think the answer works. And if it really works just in the GUI, remember there can be several GUI hooking up to some database.

I believe that the reason behind using interceptors is 2 fold:

  1. To ensure that you do not tie yourself to particular database. the porting to various DBMS is considerably simpler.

  2. To ensure that your domain model does not bleed into other parts of your code. ie the database requiring to understand about if your record has transformed.

But all of this is dependent around the context. If it is essential that all changes to specific records is neccessary i quickly think than HLGEM is correct. triggers are the most useful to handle that kind of senario.

To be sure with HLGEM. A great option to getting the benefits of getting both triggers and portability of DBMS, is by using some auditing tool that: Given an audit plan: create the triggers for that appropriate DBMS

Pablo Javier

Another small problem is by using triggers doing any DML. nHibernate uses the affected row count to find out success on lots of its procedures. If you're doing any card inserts/updates/etc. within your triggers, then you will want to show NOCOUNT on within the triggers to avoid individuals false rowcounts from bubbling up.

Not too this, by any means, prevents you against making triggers work, but I have spent sufficient time refactoring from this issue I believed it was worth mentioning. Interceptors, or EventListeners, really are a simple, portable method to satisfy auditing needs.

Plus, forget about icky T-SQL code...

Triggers aren't easily testable and they are really very difficult to create correctly. And when your audit data will be consumed by business customers, it's frequently hard to translate from database row-level procedures into the domain model.

I am of the perception that the database is actually only the persistence section of a credit card applicatoin. Of merely one application. Quite simply, I do not believe that others should use my database directly therefore i think auditing to become done outdoors from the database (i.e. avoid triggers).