Effective strategy for leaving an audit trail/change history for DB applications?

Question

What are some strategies that people have had success with for maintaining a change history for data in a fairly complex database. One of the applications that I frequently

Answer 1

Similar to a trigger (or even with) you can have every transaction fire a logging event asynchronously and have another process (or just thread) actually handle the logging. There would be many ways to implement this depending upon your application. I suggest having the application fire the event so that it does not cause unnecessary load on your first transaction (which sometimes leads to locks from cascading audit logs).

In addition, you may be able to improve performance to the primary database by keeping the audit database in a separate location.