これに関するディスカッション スレッドをいくつか見つけましたが、3 つのメカニズムすべてを 1 つのスレッドで比較するものはありませんでした。
だからここに私の質問があります...
DB の変更を監査する必要があります。ビジネス オブジェクトへの挿入\更新\削除です。
これを行うには3つの方法を考えることができます
1) DBトリガー
2) ハイバネート インターセプター
3) 春の AOP
（この質問はSpring\Hibernate\RDBMSに固有のものです-これはJava\c＃または休止状態\n休止状態には中立だと思いますが、回答がC++またはJavaまたは休止状態の特定の実装に依存している場合-指定してください）
これらの戦略のいずれかを選択することの長所と短所は何ですか?
実装の詳細については尋ねていません。これは設計上の議論です。
これをコミュニティ wiki の一部として作成できることを願っています。
これが質問に 100% 関係しているわけではないことは理解していますが、新しいオプションで付加価値が得られます。
何が起こっているかを監査するには、さらに 2 つの方法があります。
トランザクション ログの読み取り: データベースが完全復旧モードの場合、INSERT、UPDATE、DELETE、および DDL ステートメントに関するすべての詳細がトランザクション ログに記録されます。
問題は、ネイティブでサポートされていないため、読み取るのが非常に複雑なことと、ApexSQL LogやSQL Log Rescueなどのサード パーティのトランザクション ログ リーダーが必要になることです(後者は無料ですが、SQL 2000 のみをサポートしています)。
この方法の利点は、データベースを完全復旧モードにする以外は、文字通り変更を加える必要がないことです。
SQL Server トレース: トレースは、一部のコンプライアンス シナリオでも必要になる可能性がある select ステートメントを含む、トレース ファイル内のすべてをキャプチャします。欠点は、トレースが解析して整理する必要があるテキスト ファイルであることです。
データベースへの変更を監査するためにデータベース トリガーを使用しない正当な理由は思いつきません。挿入、更新、および削除は、さまざまなソースからデータベースにヒットする可能性があります。トリガーはこれらすべてをキャッチします。休止状態などはしません。
私が今偶然見つけた古い質問です。利用可能なもう1つのオプションがあります。それは、バージョン3.6以降で休止状態と一緒に利用できるEnversです。
監査を検討するときは、それが何のためにあるのかを検討する必要があります。まず、誰が何を変更したかを記録して、悪い変更を取り消すことができます。システムの問題を特定できます（いくつかの異なるアプリケーションのどれが変更を引き起こしたかを確認できるため、どれが壊れているかをすばやく特定できます）そのため、誰が変更を加えたかを特定できます。詐欺の検出に関しては、最後のものが非常に重要になる可能性があります。ユーザーインターフェイスからすべてを実行する場合、バックエンドのデータを変更して自分自身にチェックを書き込むユーザーが詐欺を犯しているのを目にすることはありません。インターフェイスからすべてを実行する場合は、テーブルレベルで権限を設定する必要がある可能性があります。これにより、最初から不正行為への扉が開かれます。あなたがインターフェースからすべてをするなら、あなたはそうするでしょう」どの不満を持った従業員が純粋な迷惑値のためにユーザーテーブル全体を削除したかを知りません。フロントエンドからすべてを実行すると、どの無能なdbaが誤ってすべての顧客注文を同じ顧客に更新したかがわかりません。そもそも監査が必要な理由のかなりの部分を失うため、監査のトリガー以外の使用をサポートすることはできません。
Hibernate インターセプターを使用して監査ログを実行することには、重大な欠陥があります。この方法の最も明白な欠陥を指摘せずに、この方法を推奨しているブログの数に私は唖然としています。つまり、インターセプターは監査を記録するために新しいトランザクションを使用する必要があります。これは、メイン トランザクションを正常に保存し、監査トランザクションの記録に失敗するシステム クラッシュが発生する可能性があることを意味します。