過去のトランザクション データを保存する方法を決定しようとしています。
レコードが毎回新しいタイムスタンプで再挿入される単一のテーブルに保存する必要がありますか?
履歴データを別の「履歴」テーブルに分割し、現在のデータのみを「アクティブ」テーブルに保持する必要があります。
もしそうなら、どうすればそれを行うのが最善ですか？データを履歴テーブルに自動的にコピーするトリガーを使用しますか? または、アプリケーションのロジックを使用しますか?
Welbog のコメントによる更新:
大量の履歴データが存在します (数十万行 - 最終的には数百万行)
主に、履歴データに対して検索とレポート操作が実行されます。
パフォーマンスは懸念事項です。結果を得るために検索を一晩中実行する必要はありません。
要件がレポートのみである場合は、別のデータ ウェアハウスを構築することを検討してください。これにより、ゆっくりと変化するディメンションなどのデータ構造を使用できます。これは、履歴レポートにははるかに適していますが、トランザクション システムではうまく機能しません。結果として得られる組み合わせにより、履歴レポートも本番データベースから移動され、パフォーマンスとメンテナンスが向上します。
この履歴をアプリケーション内で利用できるようにする必要がある場合は、何らかのバージョン管理または論理的な削除機能を実装するか、すべてを完全に反対にして再表示する必要があります (つまり、トランザクションは決して削除されず、元に戻して再表示するだけです)。非常に複雑になるため、これが本当に必要かどうかを慎重に検討してください。過去の状態を正しく再構築できるトランザクション アプリケーションを作成することは、見た目よりもかなり困難です。金融ソフトウェア (保険引受システムなど) は、あなたが思っている以上にこれを行うことができません。
監査ロギングのためだけに履歴が必要な場合は、シャドー テーブルと監査ロギング トリガーを作成します。これは、アプリケーション内に監査ログを正しく包括的に実装しようとするよりもはるかに簡単で堅牢です。トリガーは、アプリケーション外部のソースからデータベースへの変更も取得します。
この質問は、ビジネスロジックに沿っています。まずビジネス要件を理解してから、そこから始めてください。データ ウェアハウスは、この種の状況に適したソリューションです。ETL は、データ フローを処理するための多くのオプションを提供します。「歴史」対「アクティブ」の基本的な概念は非常に正しいです。すべてのディメンション テーブルとファクト テーブルを含むデータ ウェアハウスに保持すると、履歴データはより効率的かつ柔軟になります。