1

最初は、すべての監査ログを処理する 1 つのテーブルを考えていますが、柔軟性の観点から、たとえば将来的には、テーブルを分割して、各アプリケーションに独自の監査ログを持たせることが理にかなっていると思いますか?テーブル？

たとえば、予約の場合、フィールド レベルですべての変更を追跡する 1 つの監査テーブルを作成し、次にビザ申請用の別の監査テーブルを作成します。

私の現在の監査ログテーブルの設計は次のとおりです

AuditLogID
Module              
ActivityType
ReferenceNumber 
FieldName
OldValue
NewValue
IPAddress
4

1 に答える 1

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
于 2012-06-03T11:57:28.973 に答える