我們當前的企業解決方案是由實體框架驅動的ASP.NET MVC應用程序。有一些關於如何掛鉤審計變更事件的鏈接。我對此並不感興趣。企業數據審計
我對企業級審計架構感興趣。那些在企業級戰鬥中受傷的人，你的審計解決方案是什麼？您是否在框架中序列化數據庫中的對象？你是否設置數據庫觸發器來審計表？您是否一起使用單獨的數據庫，以便您的審計增長不會影響您的應用程序數據庫？我對這裏的嘗試和真正的解決方案感興趣。我知道我們的技術選擇（EF）有選項，但我首先對基金會感興趣。
鏈接將不勝感激。
我見過幾個解決方案，但我最喜歡的一個是很簡單的事：
創建審計表是鏡像每個源表，添加一些額外的列以跟蹤更改的日期和類型（如果您支持，請插入，更新或刪除）以及進行更改的用戶。刪除所有約束和索引（除非您希望進行大量搜索）。
在表更新邏輯內部（我們使用過程，但沒有理由不能用OR/M或其他持久層完成，給定相應的鉤子），寫入源表和源表審計表。
這有很多好處，但最大的一個（在我看來）是不必擔心或寫所有的代碼來管理客戶端配對寫操作的事務完整性。
雖然我們可以將這些變化掛鉤，這意味着我們可以在持久性上做到這一點，但是這裏沒有存儲過程和EF決策。所以基本上這是一個單獨的數據庫中的應用程序表的鏡像？ – RailRhoad 2009-09-17 14:51:29
這是正確的，除了在相同的分貝，這樣你會有像「員工」和「EmployeeHistory」旁邊的表。 （儘管Craig Stuntz的評論在這裏有所說明。）回想起來，我沒有理由說它假設存儲過程，所以我編輯了那些文本。 – 2009-09-17 16:16:20
這是否意味着一個數據庫必須將所有內容寫入兩次？您是否注意到這樣做會對吞吐量產生影響？ – glenatron 2012-09-14 10:31:11
我沒有任何鏈接，但在系統中，我有幸在日常工作中保持在這裏。我們有一個審計表，基本上存儲以下信息。
表名，PrimaryKeyValue，ModifiedColumn，的OldValue，的NewValue，ChangeUser，更改日期
現在，這個偉大工程的審覈速度，在我們的代碼，我們有一個自動執行的審計記錄的通用接口，但是從一個「審查」的觀點，它不是「最快」的方式來獲取信息。 （當然，我們還沒有真正做過什麼需要看審覈日誌...）
我們最近不得不在我們的企業中解決同樣的問題。我們被要求能夠恢復到之前的版本。
我們最終審覈了業務實體，而不是sql中的表。我們基本上序列化數據庫中的記錄並跟蹤從一個版本到下一個版本所做的更改。這種方法允許我們將以前的版本檢索到業務實體中，然後通過調用相同的保存操作進行恢復。這種恢復功能將轉移到應用程序責任上，因爲它必須在這裏解決，否則我們的服務可能需要知道關於參與應用程序的太多細節。 Serivce Operations根據版本，日期，查看歷史記錄以及審覈變更來檢索記錄。它針對不同的應用程序組和不同的實體（不是數據庫中的所有內容都需要進行審計，爲什麼需要審計）。
然後，我們構建一個輕量級網站，與服務對話並顯示所有版本。我們構建了一個機制來顯示添加/更新/刪除操作以比較不同版本（非常酷的UI表示），這使用戶可以查看誰更改了什麼以及何時更改。該服務可以發回一個鏈接到url來查看實體的版本。這使我們的webaps + winform/wpf應用程序能夠啓動瀏覽器，以便用戶可以看到更改。
也許我可以打包這件事，並提供如果有人有興趣....
因此，您將EF對象並序列化，然後將它們存儲在自己的審計表/數據庫中？你如何處理親子關係？ – glenatron 2012-09-14 10:29:40
也讓我再拍重要的注意事項。我們熱衷於回頭查看應用程序中的舊數據。這是我們認爲持久化序列化對象是有幫助的（不僅記錄增量）。 – RailRhoad 2009-09-17 14:53:12
一個數據庫與多個數據庫之間的區別有點人爲。數據庫可以有多個文件組，表可以有多個分區。您可以像處理多個數據庫一樣有效地處理單個數據庫，並且可以像處理多個表一樣處理單個表。 – 2009-09-17 15:02:54