Data auditing: triggers vs application code

  • From: Sandeep Dubey <dubey.sandeep@xxxxxxxxx>
  • To: oracle-l <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 21 Sep 2005 15:52:23 -0400

Hi,
 I need to keep track of history of data change in the live tables. Two
methods are being compared.
 1. Create triggers on the live table. For each insert/update/delete insert
a row in the audit table.
2. Let the application take care of inserting the data in the audit table
itself.
 The cons against using triggers in the order of severity are:
 1. If somehow the triggers are disabled in production, the application goes
through without noticing it and no audit data will be captured.
2. In a high transaction environment triggers have overhead.
 As a database person, I am inclined to use triggers. But I fail to
guarantee that trigger will never get disabled. If it is disabled somehow
application SHOULD stop. (It is impractical to check the status of all
underlying triggers before each transaction).
 I would like to hear how you guys handle data auditing in your system.
 Thanks
 Sandeep

Other related posts: