RE: Data auditing: triggers vs application code
- From: "Igor Neyman" <ineyman@xxxxxxxxxxxxxx>
- To: <dubey.sandeep@xxxxxxxxx>, "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 21 Sep 2005 16:03:56 -0400
Regarding your 2nd point:
In high transaction environment making extra trip from application to
database to log data in adit table will cause more overhead than using
trigger to populate audit table.
Now, if you are afraid that someone could disable auditing triggers,
aren't you afraid that someone could disable "auditing part" of
application?
Igor Neyman
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Sandeep Dubey
Sent: Wednesday, September 21, 2005 3:52 PM
To: oracle-l
Subject: Data auditing: triggers vs application code
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:
