テーブルを監査するためにデータベースに変更を保存する必要がある新しい Web アプリに取り組んでいます。このような監査テーブルの目的は、後で実際の物理的な監査で、ある状況で何が起こったのか、誰が何を編集したのか、複雑な計算などの時点でデータベースの状態がどうだったのかを確認できるようにすることです。したがって、ほとんどの監査テーブルは書き込まれ、読み取られません。場合によってはレポートが生成されることがあります。
利用可能なソリューションを探しました
私はこれらのどれも試したことがないので、実際の経験と、どれを使用すべきかを知りたいと思いました. たとえば、どちらがより高速で、使用するスペースが少なく、拡張と保守が簡単ですか?
個人的には、データベースに監査テーブルを作成し、トリガーを介して入力することを好みます。これにより、クエリ ウィンドウからのアドホック クエリでさえも変更が保存されます。データベース自体に基づいていない監査ソリューションは考えられません。データベースに悪意のある変更を加えたり、不正行為を行ったりする人々は、Web インターフェースを介してではなく、バックエンドで直接行う可能性が高いため、これは重要です。このようなことのはるかに多くは、外部のハッカーよりも、不満を持った、または貪欲な従業員から発生します。既に ORM を使用している場合、アクセス許可が、それらが属する sp レベルではなくテーブル レベルであるため、データが危険にさらされます。したがって、GUI からの変更だけでなく、可能な変更をデータに取り込むことがさらに重要です。新しいテーブルがデータベースに追加されるたびに実行される監査テーブルを作成する動的プロシージャがあります。監査テーブルにはレコード全体ではなく変更のみが入力されるため、フィールドが追加されるたびにテーブルを変更する必要はありません。
また、考えられる解決策を評価するときは、データを元に戻して特定の変更を元に戻すことがどれほど難しいかを考慮してください。監査テーブルを作成すると、これがテーブルから実行する必要がある最も重要なことの 1 つであることがわかります。また、データベース スキーマが変更されると、情報を維持することがどれほど困難になるかを考慮してください。
最も理解しやすいように見えるという理由でソリューションを選択することは、一般的には良い考えではありません。要件、セキュリティなどを満たした後、これは選択基準の最低値である必要があります。
それらのいずれについても実際の経験を提供することはできませんが、観察したいと思います。
AuditTrail とは、Django wiki のAuditTrail を意味すると思います。HistoricalRecordsもしそうなら、代わりに同じ著者 (Marty Alchin aka @gulopine) が彼の本Pro Djangoで開発したものを見たいと思うでしょう。Django 1.x でうまく動作するはずです。
これは、私が今後のプロジェクトで使用するアプローチです。これは、技術的な観点から必ずしも他のものよりも優れているからではなく、そのアプリケーションの監査証跡の「現実世界」の期待に一致するためです。
質問で述べたように、rcField は私のニーズには多すぎるようです。これは、変更をテーブルに保存し、後でそれらの変更に戻ってレポートを生成するという単純なものです。
だから私はAuditTrailとReversionをテストしましたReversionは、多くの機能を備えたより優れた本格的なアプリケーションのようです（これは必要ありません）。また、私が知る限り、XMLまたはYAML形式の単一のテーブルにデータを保存すると思います
AuditTrail は、各テーブルに対して対応する監査テーブルを生成するため、変更を簡単に追跡でき、テーブルごとのデータが少なく、簡単に操作でき、レポート生成に使用できるという点で優れています。
だから私はAuditTrailを使います。