ソースが挿入専用の場合、IDENTITY
列を指定します。データ転送を行うとき、書き込まれた最高値を記録します。次の転送では、前の転送で記録された値よりも大きい値のクエリのみが必要です。これは、ログレコードをデータウェアハウスに転送するために行います。
更新可能な行の場合、「ダーティ」フラグを追加します。クリーン、ダーティ、削除の3つの値があります。日常のクエリでは、フラグが「deleted」に設定されている行を省略する必要があります。これは、メンテナンス、テスト、および実行に費用がかかります。大きなクエリの後、削除対象としてマークされているすべての行を削除し、他のすべての行のフラグをリセットする必要があります。これはうまくスケーリングしません。
変更データキャプチャのより軽い代替手段は、変更追跡です。変更された値はわかりませんが、最後にクエリが実行されてから行が変更されただけです。組み込み関数により、変更された値の取得と追跡の管理が容易になります。CTを使用して、1日あたり約100,000件の変更を1億行のテーブルで処理することに成功しました。
クエリ通知は、結果セットのレベルでさらに高いレベルで機能します。概念的には、ビューを定義するようなものです。SQL Serverは、そのビューから返された行が変更されたことを検出すると、アプリケーションにメッセージを送信します。変更された行数や列は表示されません。「何かが起こった」という簡単なメッセージだけがあります。問い合わせて対応するのはアプリケーション次第です。ご想像のとおり、実際にはそれよりもはるかに複雑です。クエリの定義方法には制限があり、変更されたデータ以外の条件に対して通知が発生する場合があります。通知が発生すると、削除されます。その後、関心のあるアクティビティがさらに発生すると、それ以上メッセージは送信されません。
OPの質問のコンテキストでは、QNにはセットアップのオーバーヘッドが低く、実行時のコストが少ないという利点があります。厳密なsubscribe-message-reactレジームを確立して維持することは、かなりの努力になるかもしれません。データテーブルは大きいため、頻繁に変更される可能性が高く、ほとんどの処理サイクルで通知が発生する可能性が高いことを意味します。CTまたはCDCの場合のように、変更された差分の増分処理は不可能であることを示すものがないため。誤ったトリガーによるオーバーヘッドは面倒ですが、最悪の場合でも、高価なクエリを現在よりも頻繁に実行する必要はありません。