There are two types of audits. The first is row level that allows you to track who changed a row. Also the created and last modified time is saved. In addition there is a timestamp field for concurrency. You can turn any of these auditing features off if desired. These are extra fields appended to a table in the database and managed by the model.

The second type of auditing is at the table level. When a table is marked to allow auditing, a shadow table is created and maintained by the system, of all changes to the table. This includes additions, updates, and deletes. It is as easy as setting an entity property. All table activity is recorded no matter how the table is modified. This even includes modifications made outside of the generated framework. You can then query the shadow table to determine a row state at any point in time.

Many times it is necessary to know the state of all database rows at all points in time. Financial auditing is one use of this functionality. It can be used for database administrators (or developers) to determine when any value changes in any row in any table. This is quite a useful feature for anyone who actually has need of this functionality and quiet non-trivial to actually build. This is not information that can be retrieved unless an auditing system is in place, since a normal database only stores the current state of a row and not all past states.

Last edited May 8, 2012 at 12:43 AM by codetools, version 2


No comments yet.