[解決済み] ヒストリカルデータの保存方法【終了しました

質問

同僚と、履歴データを保存するのに最適な方法について議論になりました。 現在、いくつかのシステムでは、履歴データを保存するために別のテーブルを使用し、現在のアクティブなレコードのために元のテーブルを保持しています。 例えば、FOOテーブルがあるとします。 私のシステムでは、すべてのアクティブなレコードはFOOに、すべての履歴レコードはFOO_Histに格納されることになります。 FOOにはユーザーが更新できるフィールドがたくさんあるので、更新されたものをすべて正確に記録しておきたいのです。 FOO_Histには、自動インクリメントのHIST_IDを除き、FOOと全く同じフィールドが入ります。 FOOが更新されるたびに、FOO_Histに次のようなinsert文を実行します。 insert into FOO_HIST select * from FOO where id = @id .

同僚は、歴史的な理由からテーブルの正確なコピーを持つべきでなく、歴史的な目的であることを示すフラグを付けてアクティブなテーブルに別のレコードを挿入するだけなので、これは悪い設計だと言っています。

履歴データの保存を扱う標準はありますか？ 100万件を超えるかもしれない（長期的に考えて）ことを考えると、アクティブなレコードとすべての履歴レコードを同じテーブルで乱雑に扱いたくないような気がするのです。

あなたやあなたの会社はどのように対処していますか？

MS SQL Server 2008を使用していますが、どのDBMSでも良いので、汎用的な回答にしておきたいと思います。

どのように解決するのですか？

運用システム内で直接履歴データをサポートすると、アプリケーションは他の方法よりもはるかに複雑になります。 一般的に、システム内でレコードの履歴バージョンを操作するための厳しい要件がない限り、これを行うことはお勧めしません。

よく見ると、履歴データに対する要求のほとんどは、2つのカテゴリーのいずれかに分類されます。

• 監査ログの取得。 これは、監査テーブルを使用して行うのがよいでしょう。 システムデータ辞書からメタデータを読み込んで、監査ログテーブルとトリガーを作成するスクリプトを生成するツールを書くのは、かなり簡単です。 この種のツールは、ほとんどのシステムに監査ログを追加するために使用することができます。 また、データウェアハウスを実装する場合、このサブシステムを変更されたデータの取得に使用することもできます（下記参照）。

• ヒストリカルレポート。 過去の状態、「現状」のポジション、または時間経過に伴う分析的なレポートを報告する。 上記のような監査ログテーブルを照会することで、単純な履歴レポートの要件を満たすことが可能な場合があります。 より複雑な要件がある場合は、履歴を運用システムに直接統合するよりも、報告用のデータマートを実装する方が経済的な場合があります。
  
  
  
  ゆっくりと変化するディメンションは、履歴の状態を追跡してクエリするための最もシンプルなメカニズムであり、履歴追跡の多くを自動化することができます。 一般的なハンドラを記述するのはそれほど難しくありません。 一般に、履歴レポートでは最新のデータを使用する必要はないため、通常は一括更新のメカニズムで十分です。 このため、コアとレポートシステムのアーキテクチャは比較的シンプルに保たれます。

この2つの要件のいずれかに該当する場合は、運用システムに履歴データを保存しない方がよいでしょう。 履歴機能を別のサブシステムに分離した方が、全体的な労力も少なく、トランザクションや監査・報告用のデータベースも、本来の目的に対してより効果的に機能するようになるはずです。