views:

906

answers:

3

I am working on an new web app I need to store any changes in database to audit table(s). Purpose of such audit tables is that later on in a real physical audit we can asecertain what happened in a situation, who edited what and what was the state of db at the time of e.g. a complex calculation. So mostly audit table will be written and not read. Report may be generated though sometimes.

I have looked for available solution

  1. AuditTrail - simple and that is why I am inclining towards it, I can understand it single file code.

  2. Reversion - looks simple enough to use but not sure how easy it would be to modify it if needed.

  3. rcsField seems to be very complex and too much for my needs

I haven't tried anyone of these, so I wanted to know some real experiences and which one I should be using. e.g. which one is faster uses less space, easy to extend and maintain?

+2  A: 

I can't give you real experience with any of them but would like to make an observation.

I assume by AuditTrail you mean AuditTrail on the Django wiki. If so, I think you'll want to instead look at HistoricalRecords developed by the same author (Marty Alchin aka @gulopine) in his book Pro Django. It should work better with Django 1.x.

This is the approach I'll be using on an upcoming project, not because it necessarily beats the others from a technical standpoint, but because it matches the "real world" expectations of the audit trail for that application.

Van Gale
Yes by AudtiTrail I meant AuditTrail on the Django wiki, so for HistoricalRecords do I have to buy book or code is available?
Anurag Uniyal
Some of his other projects are online, but I can't find that particular code even at http://prodjango.com/.
Van Gale
+1  A: 

Personally I prefer to create audit tables in the database and populate through triggers so that any change even ad hoc queries from the query window are stored. I would never consider an audit solution that is not based in the database itself. This is important because people who are making malicious changes to the database or committing fraud are not likely to do so through the web interface but on the backend directly. Far more of this stuff happens from disgruntled or larcenous employees than outside hackers. If you are using an ORM already, your data is at risk because the permissions are at the table level rather than the sp level where they belong. Therefore it is even more important that you capture any possible change to the dat not just what was from the GUI. WE have a dynamic proc to create audit tables that is run whenever new tables are added to the database. Since our audit tables populate only the changes and not the whole record, we do not need to change them every time a field is added.

Also when evaluating possible solutions, make sure you consider how hard it will be to revert the data to undo a specific change. Once you have audit tables, you will find that this is one of the most important things you need to do from them. Also consider how hard it will be to maintian the information as the database schema changes.

Choosing a solution because it appears to be the easiest to understand, is not generally a good idea. That should be lowest of your selction criteria after meeting the requirements, security, etc.

HLGEM
I have choosen soft solution vs DB one( so now i am looking for a maintanable solution)B solution can not cater to app state (easily),Regarding security i think if a person has access to DB and hell bent on doing fraud what makes you think he will not remove such db audit trigger or not change the audit tables itsels unless they are being stored in 3rd physical location with heavy sec
Anurag Uniyal
+1  A: 

As i stated in my question rcField seems to be to much for my needs, which is simple that i want store any changes to my table, and may be come back later to those changes to generate some reports.

So I tested AuditTrail and Reversion Reversion seems to be a better full blown application with many features(which i do not need), Also as far as i know it saves data in a single table in XML or YAML format, which i think

  1. will generate too much data in a single table
  2. to read that data I may not be able to use already present db tools.

AuditTrail wins in that regard that for each table it generates a corresponding audit table and hence changes can be tracked easily, per table data is less and can be easily manipulated and user for report generation.

So i am going with AuditTrail.

Anurag Uniyal
Did you see this class FullHistory: http://www.djangosnippets.org/snippets/1234/ ? I began to observe problem of you question, and did't find best solution yet. Do you have any problems with AuditTrail ?
ramusus
I haven't looked into FullHistory but if it works it will be really simple solution, for now I haven't use auditTrail on production but initial test seems to suggest it will work ok
Anurag Uniyal