サード パーティの OLAP サービスへの週次データ フィードを管理するためのベスト プラクティスを調査しています。分析データベースは、完全なデータ ダンプで初期化されます。その後の週次フィードでは、新しい行と更新された行が提供されます。データは、SQL Server 2005 データベースから供給されます。
新しい行と更新された行を検出するための推奨されるアプローチは何ですか?
挿入および更新時に変更日フィールドをトリガーし、最後のフィード抽出より後のものを取得します。また
ソース テーブルのタイムスタンプ列と、前回のフィード抽出よりも大きいタイムスタンプを持つ行を取得します。また
思いもよらなかった素晴らしいアイデア...
それは、変更された行をどのように定義するかによって異なります。
番号 2 は機能しますが、実際には何も変更しない更新 (値を 1 から 1 に更新するなど) であっても、行を変更するとタイムスタンプが変更されます。ばかげているように聞こえますが、誰がそれをしますか? しかし、動的コードを使用すると簡単に実行できます。
番号 1 を変更して、トリガーで挿入されたテーブルと削除されたテーブルの間に違いがあることを確認し、オプション 2 の問題を修正できます。
ただし、関連するテーブルにある可能性のある異なる列をそれぞれ含む 3 つの異なるフィードがあり、そのうちの 1 つが実際に変更された場合にのみ送信したいとします。現在、トリガーはフィードに十分に固有のものではありません。変更データの追跡を使用して、最後の送信日 (すべての SSIS パッケージの一部として保存) 以降に変更された行を特定し、特定の列の行ハッシュ データを計算して、関心のあるデータが実際に変更されたかどうかを確認します。また、送信された内容の履歴テーブルを使用して、それらの値 (テーブル内の 1 つまたは 2 つのフィールドのみに関心がある場合) を、変更データ追跡テーブルで実際に変更された値と比較する人も見てきました。この特定の要件がある場合、それをサポートするための非常に複雑なシステムになります (大まかなアイデアを示しているだけです)。
HLGEM が言ったように、タイムスタンプは良い考えではありません。トリガーは良いオプションですが、ここで別の質問があります - 変更をどのように保存する予定ですか? すべてのレコードを履歴テーブルに複製するだけですか? 答えは、ストレージの容量によって異なります。はいの場合、または履歴レコードに限定して保存する必要がある場合 (たとえば、1 年間の履歴のみ)、それを行うことができます。ただし、ストレージが限られている場合、またはすべての変更を 1 つのテーブルに保存する場合は、私が好む方法を使用することを提案します。OUTPUT 句を使用し、変更された列の値のみを 1 つのテーブルに XML として保存します。このテクニックについては、ブログpart_1、part_2で説明しました。