Re: auditing with context?

Martin Gregorie wrote:
On Thu, 12 Mar 2009 04:30:34 -0700, Elhanan wrote:

the user when getting reports would like to know more then just a list
of fields , so it would seem that a generic method which jumps up on
each buisness method being called, only get the current context (via
interfface which would implemented differently each time) is a
condradiction in terms.

This is a system design issue rather than anything that's Java specific.

Its probably best implemented by doing all database updates through stored procedures that generate the audit log while doing any auditable database operation. If you want to record context then this must must be passed as a parameter to every stored procedure that generates audit trail entries. Context can be quite bulky: the user name, a timestamp, description of the operation and the name of the implementing class are all relevant and may be merely a subset of the context required if the system contains sensitive data. I haven't mentioned tracking field-level changes to the database - that's a given of you're doing anything like this.

However, doing this will carry costs during design and implementation as well as imposing disk storage and and processing overheads. Storage overheads need to be properly sized as they may be larger than anybody can guess. Indeed, the audit trail is probably a multi-table section of the database.

I'd say that management buy-in is essential if auditing is to be properly costed and those costs approved. Its also essential if the audit trail is actually used to track down bugs and user access violations.

Is this even a database question?

The OP discussed "fields", not a relational database concept, business methods, logic operations and parent objects. This sounds like a code-coverage question.

What confuses me is the mention of what "the user ... would like to know". This kind of auditing is rarely user-space but maintenance-space, for the benefit of operations personnel and maintenance programmers.

If this is about code coverage, it sounds like
a) rather too much work for too little benefit, and
b) a job for a logging aspect to the code.

--
Lew
.

Relevant Pages

  • Re: auditing with context?
    ... so it would seem that a generic method which jumps up on ... Its probably best implemented by doing all database updates through ... If you want to record context then this must must be ... Its also essential if the audit trail is ...
    (comp.lang.java.programmer)
  • cdt glossary 0.1.4
    ... This glossary seeks to limit lengthy misunderstandings ... basic database research and mathematics. ... When context matters, it is provided. ... It is /not/ the same as a reference. ...
    (comp.databases.theory)
  • Re: Database design, Keys and some other things
    ... except maybe that a database contains dead objects in the sense then as soon as they are in the database they stop behaving - food for another thread). ... some of their facts to establish that reason. ... to a refutation of the idea that there's any essential difference between the industry standard external identifier and the database-specific surrogate key: it's a matter of context merely, and not anything intrinsic to that data, or how it is managed. ... What is essential to this question is what their nature is. ...
    (comp.databases.theory)
  • Re: Problems binding to LDAP
    ... context in the LDAP naming services. ... # Sample access control policy: ... # ldbm and/or bdb database definitions ... // of this initial directory context. ...
    (comp.lang.java.programmer)
  • Re: Surrogate Keys: an Implementation Issue
    ... Consider a rollback database, or a ... database that must provide a complete audit trail of every change. ... One feature that would be high on my wish list would be the ability to expose system logs at an application level and further to preserve selected portions of them for long periods of time, eg., beyond checkpoints in some kind of system-supplied view. ...
    (comp.databases.theory)