Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Audit Table Design


Audit Table Design

Author
Message
kwoznica
kwoznica
SSC Veteran
SSC Veteran (211 reputation)SSC Veteran (211 reputation)SSC Veteran (211 reputation)SSC Veteran (211 reputation)SSC Veteran (211 reputation)SSC Veteran (211 reputation)SSC Veteran (211 reputation)SSC Veteran (211 reputation)

Group: General Forum Members
Points: 211 Visits: 475
Hello all,

I am building the backend of a web application and came across a scenario for the audit logging table design that I would to receive some opinions on.

There are 2 audit tables.

Table: AuditType - Contains all of the audit types
Fields: AuditTypeID, Type, Description, CreatedBy, CreatedOn, ModifiedBy, ModifiedOn

Table: AuditLog - The associated record for each Audit Type/activity we would like to record.
Fields: AuditLogID, UserID, AuditInformation, AuditDate, AuditTypeID, CreatedBy, CreatedOn, ModifiedBy, ModifiedOn

Those two tables will be reacting to the following events (AuditType): Password Change, Logins, Logouts, Login Failure, SessionTimeout, LoginCreation, LoginDeletion

The client would like to record more detail of what occurs with the user login information. Below are two tables with fields for each login profile.

Table: UserProfile - Contains basic user login information
fields: UserDetailId, UserID, FirstName, LastName, BusinessPhone, CellPhone, PrimaryEmail, SecondaryEmail, StreetAddress, CityID, Zip, BusinessTitle, WebAccess, Createdby, Createdon, ModifiedBy, ModifiedOn.

Table:UserCustomerRelation - Linking table to associate UserProfile Records to Customers
Fields: UserCustRelationID, UserID, CustomerId, FromDate, ToDate, CreatedBy, CreatedOn, ModifiedBy, ModifiedOn


Now if a field in the UserProfile table is modified we would like that action logged. For instance if a user with a login of jsmith had 2 new customers added to his login via the UserCustomerRelation table, those new record creations would be logged.

My initial thought is to expand the AuditTypes to include new types: Customer Add, Customer Remove,Street Address Change, Primary Email Address, First Name, Last Name, Web Access.
This way when any of these fields in the UserProfile table are modified a trigger would write to the AuditLog table with the correct type.

Is this thought the optimal way of logging such activity?
what is a more optimal way to perform logging?
Would a separate trigger need to be created for each field we wish to log?
Michael L John
Michael L John
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2051 Visits: 7382
kwoznica (2/15/2014)
Hello all,

Is this thought the optimal way of logging such activity?
what is a more optimal way to perform logging?
Would a separate trigger need to be created for each field we wish to log?



Is this optimal? Maybe. What are your audit requirements? Here are some things to consider. Auditing should be separate from your production data. This is a typical requirement. Review the requirements again. And again. And again. Have the actual auditors review your plan. You may the tracking the correct data, but the METHOD you are using to track the data may not fit the audit requirements. For example, we had our audit plan rejected because the same DBA's had access to the source data and the audit data. These needed to be separate persons.

More optimal? From what perspective? Performance? Meeting or exceeding audit requirements? Architecture?
My first generic thought was that a single audit table will probably not scale well. Separate audit tables for each "table" you are auditing may make more sense. If you are going to do this with triggers (Ugh!) the contention for this table from multiple places may become a blocking and locking issue. It may work well for 10 users, but it will become an issue with 100. The audit table may be a good candidate for a heap. The activity on this table will likely be primarily inserts, so make inserts as fast as possible. Indexes will slow this down.

Would a separate trigger need to be created for each field we wish to log?
Huh? Sounds like a trip to Books Online land is in order. Look up UPDATED
Sample syntax:
If UPDATED(field) Begin
Do something
End

You need three triggers (Ugh!); insert, update and delete.

Lastly, do some significant performance testing. Capture your baselines when you do 100, 10000, and 1000000 inserts/updates/deletes on the tables to be audited. Then add your triggers and do the same test.

Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)

Group: General Forum Members
Points: 44871 Visits: 39850
Michael L John (2/15/2014)
You need three triggers (Ugh!); insert, update and delete.


Actually, you don't. Just calculate whether it's an INSERT, UPDATE, or DELETE and mark a column with I, U, or D. Remember that when a trigger fires, it won't contain mixed events. It will be because of an INSERT, UPDATE, or DELETE and never a mixture.

If I recall correctly, here's one of the faster ways to determine what the triggering action was.

     IF NOT EXISTS (SELECT TOP 1 1 FROM DELETED)
SELECT @TriggerAction = 'I'
ELSE IF NOT EXISTS (SELECT TOP 1 1 FROM INSERTED)
SELECT @TriggerAction = 'D'
ELSE SELECT @TriggerAction = 'U'
;



--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
     Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Michael L John
Michael L John
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2051 Visits: 7382
Correct. But.
I prefer three separate triggers (Ugh!) for task such as this. To me, it's easier to maintain. And it's also easier to sort through the spaghetti with separate triggers (Ugh!).

You may end up with extra maintenance because the code is duplicated in all three triggers (Ugh!).

Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search