1

ソーステーブルから宛先テーブルへのデータフローがあります。質問を単純化するために、2つのマージ結合されたソーステーブルと1つの宛先テーブルがあると言います。また、各レコードを識別するのに役立つ主キーがあります

パッケージは毎日実行されており、ソーステーブルから1つのレコードが削除された場合、宛先テーブルでそのレコードを削除できるように、どのレコードが削除されたかをどのように知ることができますか？

（FYI ~~宛先テーブルにレコードが存在するかどうかを確認し、存在する場合は更新しますが、削除されたデータを見つける方法がわかりません）

4

4 に答える 4

0

ソースと宛先を比較する際の問題は、すべてのロードですべてのソース行を宛先と比較する必要があり、行数が増えると時間がかかることです。

結果として、これを処理する最良の方法はおそらくソース側にあります。2つの一般的なアプローチは、行を削除済みとしてマークするフラグ列を設定する「ソフト削除」です。または、削除された行のPKをログテーブルに記録する（または行全体をアーカイブログテーブルに移動する）トリガー。次に、ETLプロセスはフラグまたはログ/アーカイブテーブルを調べて、最後のロード以降に削除された行を判別します。

もう1つの可能性は、ソースプラットフォームが、SQL ServerのCDCなど、削除された行を追跡するために使用できる組み込み機能を提供していることです。ただし、ソースデータベースをまったく制御できない場合（データベースである場合でも）、完全なデータセットを比較する以外に方法がない場合があります。

于 2012-07-24T18:45:31.330 に答える
0

考えられるアプローチの1つ：

  1. パッケージを実行する前に、宛先テーブルレコードを削除します（ストアドプロシージャを使用）
  2. すべてのレコードを宛先テーブルにインポートするだけです

長所：

宛先テーブルは常に受信データをミラーリングし、削除をチェックする必要はありません

短所：

履歴情報はありません（必要な場合）

于 2012-07-25T13:34:40.793 に答える
0

別の可能なアプローチ：

インポートと更新だけでなく、ソースからすべてのレコードを受け取ると仮定します。

  1. パッケージを修正して、一意のIDまたは実行日時を使用して挿入または更新されたレコードにスタンプを付けます

  2. パッケージの実行に続いて、最後のパッケージの実行でレコードが挿入または更新されなかった宛先テーブルを処理します。削除のプロセスにより、ソースファイルで提供されなかったレコードはすべて削除する必要があります。

繰り返しますが、インポートと更新だけでなく、すべてのレコードが送信されると仮定します。ただし、すべてのレコードを受信しないと、レコードが削除されたかどうかを物理的に検出できなくなります。

于 2012-07-25T13:38:23.833 に答える
-1

古い/アーカイブレコードが元のデータソースに存在しなくなったために「削除済み」としてマークする方法と同じ問題がありました。

基本的に、2つのテーブルを作成しました。1つは元のデータソースからのすべてのレコードを含むメインテーブルで、もう1つはスクリプトを実行するたびに元のデータソースを保存するための一時テーブルです。

メインテーブル

ID, NAME, SURNAME, DATE_MODIFIED, ORDERS_COUNT, etc
plus a STATUS column (1 for Active, 0 for Deleted)

TEMP TABLEは元のテーブルと同じですが、STATUS列はありません

ID, NAME, SURNAME, DATE_MODIFIED, ORDERS_COUNT, etc

重要なのは、MAINテーブルのIDがTempテーブルに存在しなくなった場合に、 MAINTABLEをSTATUS=0で更新することでした。すなわち：ソースレコードが削除されました。

私はこのようにしました：

UPDATE m
SET m.Status = 0
FROM tblMAIN AS m
    LEFT JOIN tblTEMP AS t
        ON t.ID = m.ID
WHERE t.ID IS NULL
于 2018-10-23T03:45:14.937 に答える