爲了審計目的，創建每個Web應用程序模塊的單獨表格是否好？

最初，我正在考慮一張將處理所有審覈日誌的表格，但在靈活性方面，例如將來您會認爲，打破錶格並讓每個應用程序擁有自己的表格審計日誌表？爲了審計目的，創建每個Web應用程序模塊的單獨表格是否好？

舉個例子，就預約而言，我會有一個審計表，它將跟蹤所有的現場級別的變化，然後我將有另一個審計表來申請簽證。

我目前的審計日誌表的設計是這樣的

AuditLogID 
Module    
ActivityType 
ReferenceNumber 
FieldName 
OldValue 
NewValue 
IPAddress

檢查這個環節，希望這會給你一些想法http://stackoverflow.com/questions/9781534/how-can-i-get-updated -column-名從 - 不同桌和插入，其數據-W –

你所描述的模式似乎是沿着實體的線屬性值（EAV），也就是每場一行。

假設所有領域的變化在所有模塊的所有表都將導致一個新的審計行，還有這種方法的一些潛在問題

你也可能錯過了2個重要的屬性審計，變更

的即用戶ID和時間戳有可能是一些標準化，你可以做你的審計表，例如有一個「每行一個」審計表和一個「每場一個」審計表。例如IP地址，ReferenceNumber，活動類型，UserId和TimeStamp可能是同一行中所有更新字段的常量，它們由單個「操作」更改並且每行屬於一次。

也有其他的替代品每直播表

一個審覈表，這是一般的字段的克隆，加上時間戳字段和一個新的主鍵（或只是把它作爲一個堆）
SQL變化數據捕捉 SQL Server 2008 change data capture vs triggers in audit trail
如果來自同一個應用程序發生的所有變化，您可以使用文檔存儲（例如存儲行作爲XML，斑點或其他元數據），保持變化的序列化版本在單排，可能只是暴露了幾個可索引字段（列名，日期）查詢的目的。
如果您選擇文檔存儲方式，您可能還會選擇不將審計數據存儲在RDBMS中。 NoSQL的商店像 RavenDB或MongoDB的擅長存儲高容量

2012-06-03 11:57:28 StuartLC

回答