Re: Data auditing: triggers vs application code

Sandeep,

I think that you should do everything in the application. You will have much less overhead, since you will multiply statements in your application (which will be written by developers much better than those who work on the Oracle kernel) and round-trips; with a little luck, your developers will even hard-code everything, so as to be certain that every statement is properly parsed (you can never be too cautious). Moreover, since anybody will be able to modify data in SQL*Plus without being noticed, you will no longer have to worry about triggers being disabled. That's definitely the way to go.

HTH

SF

Sandeep Dubey wrote:

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


--
http://www.freelists.org/webpage/oracle-l

Other related posts: