必要に応じて、Microsoftベースのテクノロジ（MS SQL Server、C＃、EABなど）のみを使用して、データベース内のレコードで行われた変更を追跡します。どの戦略を使用しますか？トリガー、DALのAOP、その他？そして、収集したデータをどのように表示しますか？それについてのパターンはありますか？この種のソリューションの実装に役立つツールまたはフレームワークはありますか？
2213 次
3 に答える
2
変更データキャプチャの問題は、実際の監査には十分な柔軟性がないことです。必要な列を追加することはできません。また、デフォルトでは3日ごとにレコードをダンプします（これは変更できますが、永久に保存できるとは思いません）。そのため、次のデータを保持する必要がある場合は、レコードを実際の監査テーブルにダンプする必要があります。長い間、これはレコードを監査する必要性の典型です（監査レコードをダンプすることはありません）。
私はトリガーアプローチを好みます。複数のレコードが変更された場合にトリガーがデータをキャプチャするように、トリガーを作成するときは注意する必要があります。監査されるテーブルごとに2つのテーブルがあります。1つはアクションを実行したユーザーまたはプロセスの日時とIDを格納し、もう1つは新旧のデータを格納します。私たちは多くの複数の記録プロセスを行うので、これは私たちにとって重要です。誰かが1つの悪いレコードを報告した場合、それが変更を行ったプロセスであったかどうか、もしそうであれば、他のどのレコードも影響を受けた可能性があるかどうかを確認できるようにします。
監査プロセスを作成するときに、一連の監査済みデータを古い値に復元するためのスクリプトを作成します。すでにこれを設定している場合は、問題を解決するために銃の下にいるときにこれを行う方がはるかに簡単です。
于 2011-03-16T14:44:11.330 に答える
2
Sql Server 2008 R2には、この機能が組み込まれています-オンラインブックのデータキャプチャの変更を検索します
于 2011-03-16T12:43:53.370 に答える
1
これはおそらく一般的な意見ではありませんが、とにかくそれを捨てるつもりです。
私はすべてのデータベース書き込みにストアドプロシージャを好みます。監査が必要な場合は、ストアドプロシージャのすぐそこにあります。コードの外で魔法が発生することはありません。発生するすべてのことは、書き込みが発生した時点で文書化されます。
将来、テーブルを変更する必要がある場合は、ストアドプロシージャに移動して変更を加える必要があります。監査を更新する必要性は、その場で文書化されています。また、ストアドプロシージャを使用したため、テーブルとその監査テーブルの両方を「バージョン管理」する方が簡単です。
于 2011-03-16T15:11:18.200 に答える