MVC Web アプリ用のデータベースの設計を開始しようとしています。データベースに加えられたすべての変更を追跡するために、'changes' または 'events' と呼ばれるテーブルを使用することを検討しています。テーブル名、レコード ID、変更を行ったユーザー、タイムスタンプ、およびそれが作成または変更イベントであったかどうかのフィールドがあります。
私の質問は、各テーブルに「作成者」、「作成者」、「変更者」、「変更者」のフィールドを持つことに比べて、これが貧弱な設計慣行であるかどうかです。親の Model クラスでは、すべての変更を記録する保存前関数を使用することを考えていました。多くのレコードが一度に更新された場合、変更を適切に保存する機能を取得するのが難しい可能性があるという落とし穴があることがわかります。
これは、データベース内の何かが変更されるたびにこのテーブルに書き込むオーバーヘッドと追加のストレージが必要になることに対して、詳細な情報を持つことの利点を比較検討する問題です。
モデル クラスで関数を使用することに懸念がある場合は、代わりにデータベース トリガーを使用できます。これは非常に堅牢ですが、使用しているデータベースに DML の変更を一般的にログに記録する機能がない限り、テーブルごとにトリガーを定義する必要があるため、設定するのに手間がかかります。
最後に、このテーブルは非常に急速に大きくなる可能性があるため、アーカイブを検討することもお勧めします。
必要なものによって異なります。イベント テーブルを作成して維持する理由は、変更の監査証跡を維持するためです。
一部のアプリケーションでは、行の最後にある作成/更新されたフィールドは十分な監査証跡です。
より安全なアプリケーションには、イベント テーブルが必要です。また、イベント テーブルに実際の変更 (前/後) を含める必要があります。