實現我們的應用程序中的審計跟蹤

Question

我想在任何添加/刪除/更新操作發生，我會記錄它，增加審計跟蹤我們的系統，具有以下信息： -

1. 的CRUD操作類型。它是添加，刪除還是更新。

2. 已修改的記錄ID。

3. 日期和時間。

現在我發現了兩種方法， 要麼具有單個審計跟蹤表具有以下字段： -

• ID。如123445.
• CRUD_description。如刪除
• Record_ID。如Qaeop12771
• 日期。如1june2O13

或者到有兩個表一個用於爲操作CRUD諸如

• CRUD_ID的查找表。如3.
• CRUD_Description.such作爲刪除。

然後審計試驗將參考上面的表中： -

• ID。如123445.
• CRUD_ID（這將是CRUD表的外鍵），例如3.
• Record_ID。如Qaeop12771
• 日期。如1june2O13

那麼哪種方法更好？

第二個問題如果我會按照第二種方法。然後是它傾向於使用CRUD_ID我的代碼裏面，例如，如果oprration是刪除我可能有我的代碼如下所示： -

Inset into audit_trail (ID, CRUD_ID, Record_ID, Date) values (123445, 3,12771,1june2O13) //CRUID 3 represents delete operation. 

問候

Answer 1

從數據庫設計的角度來看（忽略數據庫功能和應用架構），我會更喜歡具有通過實施平爲表按每個實體和領域的變化審計跟蹤（更改歷史記錄）的表稱爲Trail_History沒有外鍵的任何表，列將是：

1. UserCode：應用程序用戶唯一標識符，表示由誰進行更改。（強制性）
2. TransactionCode：任何CRUD操作都需要具有唯一的交易代碼（如GUID）（必選）
3. ChangeDate：交易日期。 （必需）
4. EntityName：正在操作的實體（表）
5. FieldName：實體字段名稱。
6. OldValue：實體字段舊值。
7. NewValue：實體字段新值
8. OperationType：CRUD操作鑑別符。 （強制）

有了這個方法
任何實體（表）可以追溯到
報告將是可讀的
只有變化將被記錄。
事務代碼將是通過單一操作檢測更改的關鍵點，第二個問題將得到解答。

希望有幫助。

Answer 2

真的這兩種方法都是非常相似的。

如果您需要新的審計操作，您需要在類型表中插入一條新記錄，seond one將更加有效但不太靈活。

問題你需要審覈多少信息更有趣。因爲說三個用戶在彼此之後更新記錄，你仍然不知道誰在你的設計中改變了什麼。