現在のエンタープライズソリューションは、EntityFrameworkによって駆動されるASP.NETMVCアプリケーションです。監査のために変更イベントにフックする方法については、いくつかのリンクがあります。私はこれにはあまり興味がありません。
エンタープライズレベルの監査アーキテクチャに興味があります。エンタープライズレベルの戦いの傷を負っている人たち、あなたの監査ソリューションは何でしたか？フレームワーク内のデータベース内のオブジェクトをシリアル化しますか？テーブルを監査するためのデータベーストリガーを設定していますか？監査の拡大がアプリデータベースに影響を与えないように、個別のデータベースをすべて一緒に使用していますか？私はここで実証済みの真の解決策に興味があります。私たちのテクノロジーの選択（EF）には選択肢があることは知っていますが、最初に基盤に興味があります。
リンクをいただければ幸いです。
リンクはありませんが、このシステムでは、日中の仕事でここを維持することができて嬉しいです。基本的に次の情報を格納する単一の監査テーブルがあります。
TableName、PrimaryKeyValue、ModifiedColumn、OldValue、NewValue、ChangeUser、Change Date
これは監査速度に最適です。コードでは、監査ログを自動実装するための共通のインターフェースがありますが、「レビュー」の観点からは、情報を元に戻すための「最速」の方法ではありません。（実際には、監査ログを確認するために必要なことは何もしていません...）
私たちは最近、私たちの企業でこれと同じ問題を解決しなければなりませんでした。以前のバージョンにも戻すことができる必要がありました。
最終的に、SQLのテーブルではなくビジネスエンティティを監査することになりました。基本的に、DB内のレコードをシリアル化し、あるバージョンから次のバージョンに加えられた変更を追跡します。このアプローチにより、以前のバージョンをビジネスエンティティに取得してから、同じ保存操作を呼び出すことで元に戻すことができます。元に戻すこの機能は、ここで解決する必要があるため、アプリケーションの責任にシフトされます。そうしないと、サービスが参加しているアプリケーションに関する詳細をあまりにも多く知る必要がある場合があります。バージョン別、日付別、履歴の表示、そしてもちろん変更を監査するためのサービス操作が提供されています。さまざまなアプリケーショングループおよび内部のさまざまなエンティティに対するオプトインアプローチです（DB内のすべてを監査する必要があるわけではないので、なぜそうするのですか）。
次に、サービスと通信し、すべてのバージョンを表示できる軽量のWebサイトを構築します。追加/更新/削除を表示してバージョン間で比較するメカニズム（本当にクールなUI表現）を構築しました。これにより、ユーザーは誰がいつ何を変更したかを確認できます。サービスは、URLへのリンクを送り返して、エンティティのバージョンを表示できます。これにより、webaps + winform / wpfアプリがブラウザーを起動して、ユーザーが変更を確認できるようになります。
たぶん私はこれをパッケージ化して、誰かが興味を持っているなら提供することができます....
私はいくつかの解決策を見てきましたが、私のお気に入りの解決策は単純さそのものでした。
各ソーステーブルをミラーリングする監査テーブルを作成し、変更の日付とタイプ（サポートしている場合は挿入、更新、または削除）と変更を行うユーザーを追跡するための列をいくつか追加します。すべての制約とインデックスを削除します（多くの検索を行うことが予想される場合を除く）。
テーブル更新ロジック内（プロシージャを使用しましたが、適切なフックがあれば、OR / Mまたは他の永続層で実行できなかった理由はありません）、ソーステーブルと監査テーブルの両方に書き込みます。
これには多くの利点がありますが、（私の意見では）最大の利点は、クライアントでのペアの書き込み操作のトランザクションの整合性を管理するために、すべてのコードを心配したり書き込んだりする必要がないことです。