アプリケーション内での監査ログの最適な方法を決定しようとしています。ログの主な理由は、一連のイベント (変更) を報告することです。
オブジェクトの階層があり、後でその階層のいずれかの部分で何かが変更されたときにレポートを作成する必要があります。
次の 3 つのオプションがあると思います。
私は現在、オプション1に傾いています。
私はそれが古いのにこの主題と話さなければなりません。
すべてがそのテーブルにヒットするとデータベースにロックの問題が発生するため、通常、監査テーブルを1つだけにすることはお勧めできません。テーブルごとに個別の監査テーブルを使用します。
また、アプリケーションに監査を行わせることもお勧めできません。監査はデータベースレベルで実行する必要があります。そうしないと、一部の情報が失われるリスクがあります。データは、ほとんどのデータベースのアプリケーションからのみ変更されるわけではありません。10％の値上げが必要な場合、ユーザーインターフェイスから一度に1つずつすべての製品の価格を変更することはありません。監査では、一部の変更だけでなく、すべての変更をキャプチャする必要があります。これは、ほとんどのデータベースのトリガーで実行する必要があります（SQL Server 2008には監査機能が組み込まれています）。考えられる最悪の変更（従業員が詐欺を犯したり、悪意を持ってデータを破壊したい）も、特にユーザーにテーブルレベルのアクセスを許可している場合は、アプリケーション以外の場所からのものであることがよくあります（財務データベースや個人情報）。アプリケーションからの監査では、これは検出されません。開発者は、データを保護する上で、外部ソースだけが脅威ではないことを忘れがちです。
監査ログは基本的に、発生したイベント、これらのイベントの実行者、およびイベントの内容を時系列で示したリストです。
簡単に注文してクエリできるので、フラットビューの方が良いと思います。だから私はあなたのオプション＃2 /＃3にもっと傾いています。
トランザクションの種類、時間、ユーザー ID、変更内容の説明、および製品に関連するその他の関連情報などを含めます。
時間をかけて製品に追加することもでき、監査ログ モジュールを継続的に変更する必要はありません。
監査目的の場合は、同じデータベース内のテーブルではなく、真の追加専用メディアを使用します。
あなたはそれが変更履歴の目的であることを示唆しています-その場合、アプリケーション/データベースを再構築して、現在の状態だけでなく、実際のイベントを最初に記録します。
(2) と (3) を使用します。すべての監査エントリに対して単一のテーブルを作成します。
余分な作業の平坦化がパフォーマンスに影響を与えない限り、フラット ビューは適切です。
これを支援するために、AOP フレームワークを調べることができます。任意/すべてのメソッドの最初または最後にロギング機能を挿入できます。この道をたどると、ログ データの保存に何が意味があるかを定義するのに役立つかもしれません。