Since the reporting will usually be done by an administrator, a little bit
of time delay probably isn't a big deal.  The administrator will be willing
to pay the price because he knows it's important, and the extra load will
only be coming from one person, so it won't affect the server much.

However, make sure you can still recrete the audit log is some of the
records in the related tables are deleted.  You don't want all the actions
that a user took to vanish from the logs if their user account is deleted.

For the main system I work on, we keep foreign keys to various non-log
tables, but we also store enough information within the log record itself so
that it remains useful in isolation.  As long as the foreign key is NOT
NULL, we allow people to jump from the log entry to the full data of the
referenced element, but the logs are still useful even without that ability.

logID int not null,
userID int null,
documentID int null,
... Etc ...
action varchar(255),
result text,
... Etc ...

Cheers,
barneyb

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 03, 2004 5:43 AM
> To: CF-Talk
> Subject: Application logging & normalisation?
>
> Hi all,
>
> Just like your thoughts on this. I've got an application well
> on the way, with a fully normalised & relational (we'll say
> it is for arguments sake!) Oracle database running the show
> underneath. I've got a db table dedicated to keeping logs of
> the activity this application will produce, which in keeping
> with the relational model has about 5 links to other tables.
>
> Bearing in mind this log table will store a significant
> amount of data when the applications fully operational - and
> the data will act as an audit trail - do you recommend:
>
> a) Keep the table relational with the rest of the
> database (5 table links, potential for slow querying to
> produce reports)
> b) Have the table as a 'dump' whereby all data except
> the primary key is inserted and there are not relational
> links (faster querying for reports)
> c) Any other suggestions?
>
> Cheers,
> Rob
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to