これは、履歴データの保存 (メイン テーブルで変更される可能性のあるサイド テーブルにデータを保存する) について昨日尋ねた質問の詳細なフォローアップであり、質問を絞り込もうとしています。
アプリケーション レベルでデータ オブジェクトを表すテーブルがあり、履歴の目的でそのテーブルが必要な場合、情報を削除できない場所にテーブルを設定することは悪い習慣と見なされます。基本的に、作業者の安全要件を表すテーブルがあり、これらの要件を削除または変更できないようにしたいと考えています。そのため、変更が必要な場合は、新しいレコードが作成されます。
これは良い考えではありませんか？このようなデータを処理するためのベスト プラクティスは何ですか? 過去の安全トレーニング データを含むテーブルがあり、要件データ (およびその他の主要なテーブル) を含むテーブルを指しているため、要件を変更することはできません。そうしないと、履歴テーブルが間違った情報を指すことになります。
これは良い考えではありませんか？
あなたのシナリオは私には完全に有効に思えます。保持する必要がある履歴データがある場合、その要件を満たすためのさまざまな方法があります。
オプション 1 :
すべての履歴データと現在のデータを 1 つのテーブルに保存します (作成日を保存して、古いものと新しいものがわかるようにしてください)。誰かの最新のレコードを取得する必要がある場合は、テーブルに存在する最新の日付に基づいてください。
オプション 2 :
すべての履歴データを別のテーブルに保存し、現在のデータを別のテーブルに保存します。これは、何百万ものレコードを操作している場合に役立つ可能性があるため、その上に構築されたアプリケーションのパフォーマンスが低下することはありません。新しいレコードの作成時または夜間のジョブのいずれかで、古いデータを他のテーブルに移動して、現在のテーブルを軽量に保つことができます。
これは必ずしも「より良い」とは限りませんが、心に留めておくべきことです...
「アクティブ」テーブルと「履歴」テーブルを別々に作成し、トリガーを作成して、アクティブ テーブルの行が変更または削除されるたびに、古い行の値がタイムスタンプとともに履歴テーブルにコピーされるようにすることができます。
このようにして、アプリケーションはアクティブなテーブルを自然な方法で操作でき、変更の正確な履歴が履歴テーブルに自動的に生成されます。また、これは DBMS レベルで機能するため、アプリケーションのバグに対する耐性が高くなります。
もちろん、オブジェクトのグラフ全体 (つまり、FOREIGN KEY を介してリンクされた複数のテーブル) の履歴を維持する必要がある場合、事態はさらに複雑になる可能性があります。おそらく最も簡単なオプションは、履歴テーブルの参照整合性を無視し、アクティブなテーブルだけを維持することです。
それがプロジェクトのニーズに十分でない場合は、変更の瞬間にグラフ全体の「スナップショット」を何らかの形で表す必要があります。これを行う 1 つの方法は、接続もバージョン管理されたオブジェクトとして扱うことです。または、エンドポイント オブジェクトの各バージョンとのすべての接続をコピーすることもできます。どちらの場合も、ロジックが大幅に複雑になります。