Question

Initially, I’m thinking of one table that will handle all the audit logs but in terms of flexibility, like for example in the future do you think, it will make sense to break the table and have each application to have their own audit log table?

Like for example, for reservation, I’ll have one audit table that will track all the changes on the field level, and then I’ll have another audit table for visa application.

My current audit log table design is like this

AuditLogID
Module              
ActivityType
ReferenceNumber 
FieldName
OldValue
NewValue
IPAddress

Answer 1

The pattern you are describing seems to be along the lines of Entity Attribute Value (EAV), which is one row per field.

Assuming that all field changes to all tables in all of your modules will result in a new audit row, there are some potential issues with this approach

• the audit table will get very huge
• the number of writes will be large and frequent and could negatively impact performance – correct clustering of this audit table will be important
• in order to view / compare rows, you will need to reassemble fields back into rows in order to be meaningful to a user

You are also potentially missing out on 2 important attributes to audit, viz UserId and TimeStamp of the change

There is probably some normalisation you can do to your audit tables, e.g. Have a ‘one per row’ audit table and a ‘one per field’ audit table.
e.g. IP Address, ReferenceNumber, Activity Type, UserId and TimeStamp are probably a constant for all updated fields in the same row which were changed by the single ‘action’ and belong at once per row.

There are also other alternatives

• One Audit table per Live table, which is generally a clone of the fields, plus a TimeStamp field and a new Primary Key (or just leave it as a heap)
• SQL Change Data Capture
  SQL Server 2008 change data capture vs triggers in audit trail
• If all changes occur from the same App, you can use a Document Store
  (e.g. store the rows as Xml, Blobs or other Metadata), keeping
  serialized versions of the change in a single row, and possibly just
  exposing a couple of indexable fields (Column Name, Date) for query
  purposes.
• If you choose the Document store approach, you might also
  choose not to store audit data in a RDBMS at all. NoSQL stores like
  RavenDB or MongoDB are good at storing high volumes