On Wed, 23 Jan 2002, Justin Clift wrote:
> Hi Gavin,
>
> I can see the usefulness of this concept from a "Data Security" point of
> view.
>
> At one place I worked, it was known one of the marketing people had a
> reputation of gathering customer details before leaving a job, just so
> he had something to bargain a pay increase with for his next job. Don't
> know why people hire a guy like that (I wouldn't), but these people
> exist.
This is an administration/management issue. Whilst auditing of a database
would provide you with a large amount of data about the actions of, say,
the marketing department, it is not a solution to the problem. The real
solution is solved at the system privileges/application level.
An auditing trail is much more useful for application debugging, load
assessment, planning etc.
>
> It should definitely be optional, and if not turned on for an object I
> don't think it should have an associated noticable performance penalty.
A user would turn auditing on. Eg
AUDIT INSERT;
or,
AUDIT ALTER ON TABLE users WHENEVER NOT SUCCESSFUL;
This pretty much replicates the oracle syntax. How much it would different
from this kind of syntax I don't know.
Auditing would result in performance issues -- but new features generally
do. The thing with auditing is that it would generally not be used in
production systems which relied on high performance. There is still the
performance cost of hitting the cache to see if the particular query is to
be audited. I would look at this cost when I started to implement it.
Thanks,
Gavin
