短期間の非常に一時的なデータの処理に関する「一般的な慣行」または一般的な「許容される慣行」について誰かが話すことができますが、何年にもわたる歴史的な存在が必要です...
たとえば、ツアーの予約をしている小さな旅行会社を考えてみましょう。旅客マニフェストは、ツアーまで非常に流動的です.. ツアーが完了すると、データは技術的には時代遅れですが、レポートやトレンドには役立ちます...
ボリュームが大きい場合 (ツアーの「検索」または「作成」)、db はめったに変更されないデータで厚くなります。
同様の構造を持つテーブルを持つことは一般的ですか - データをある状態から別の状態に「移動」します (PRE/POST イベント)...「純粋な」レポート用のセミフラット構造にデータを保管する前の暫定的なものとして
それは賢明ですか、一般的ですか、それとも正しいですか？それを行うためのより良い方法はありますか...または、ドームDBAが出入りして「WTFはあなたが考えていた」
標準は、レコードの陳腐化を示す何らかのフラグを持つことです。プルーニングやインデックス作成などのパフォーマンスの問題にうまく対処できる方法がいくつかあります。これらには、おそらく何らかのアーカイブ戦略も含まれるでしょう。テーブルから古いデータを移動する可能性があります (頻度と時期はパフォーマンス要件によって異なります)。同じ構造の履歴テーブルに何らかの一括挿入を行います (これを実際に実装する方法は DBMS によって異なりますが、最も堅牢な方法) または、DBMS に堅牢なパーティショニング システムがある場合は、何らかの並べ替えまたはパーティショニング戦略を使用することをお勧めします。また、履歴データを必要とするアナリストと運用システムを実行する担当者が異なる場合は、何らかのマルチデータベース アーカイブ戦略を検討することもできます。
もちろん、そのような設計上の決定は他の要因に依存します。ただし、一般に、あるテーブルから別のテーブルにデータを移動することはお勧めできません。
より良いオプションは、記録に有効日と終了日を設定することです。したがって、誰かがツアーにサインアップすると、その記録はその日付の発効日から始まります。彼らが脱落した場合、その人は終了日を取得します。再度サインアップすると、新しい有効日で新しいレコードが取得されます。
これにより、過去の任意の時点で履歴を再構築できます。