

How To Use Triggers to Track Changes in MySQL - edw519
http://codespatter.com/2008/05/06/how-to-use-triggers-to-track-changes-in-mysql/

======
subwindow
This is a maintenance nightmare. Now, whenever you add/change/remove a column,
you not only have to update the table definitions, but you have to update the
triggers as well. Chances are you'll forget and then updates will start
failing all over the place, and the last place you'll look is the triggers.
What about deleting the row? Do you clean up the history too? Either way you
need a delete trigger as well.

Audit logging like this should be handled on the application level. That way
you get to know _who_ did the change, which is generally one of the most
important parts of an audit trail.

~~~
henning
See "choose a single layer of cleverness" at
<http://www.loudthinking.com/arc/2005_09.html> (can't permalink because he
partially recovered from a crash).

~~~
nradov
That's all well and good if you have a single layer of business logic
operating on a particular database. But in the real world you may have
multiple completely separate pieces of business logic, often written in
different languages. It that situation, the database itself becomes the only
place to put shared code to ensure that rules are followed.

~~~
henning
This is where Martin Fowler's distinction between application databases and
integration databases comes in. If your app is the only one hitting the
database, things are much simpler.

