多くの列を持つ行のハッシュまたはチェックサムを計算する最も効率的な方法は？

Question

ターゲットデータベースの行をソースデータベースから更新する必要があるかどうかを確認する必要があるシナリオがあります。ソースデータは実際にはビューであり、そのビューからのデータは宛先テーブルにポンピングされます。ソースビューはいくつかの基になるテーブルからデータを収集/ロールアップ/ピボットするので、変更トラッキングをサポートするためにスキーマを変更するのに良い方法はありません。そのため、各行のデータのハッシュを計算し、ビューの一部。次に、宛先テーブルのハッシュ値を比較して、相違点があるかどうかを確認し、それに応じて更新することができます。

私は承知している：

CHECKSUM 
BINARY_CHECKSUM 
HASHYBYTES 

機能。 CHECKSUM（）またはBINARY_CHECKSUM（）のいずれかが最善の選択肢だと思われますが、50列と100万行以上のビューでどれくらいうまく動作するかはわかりません。また、生成されたチェックサム/ハッシュが編集後でも異なることはないことに気付いていますが、この場合は許容されます。

質問：これを行うにはハッシュ/チェックサムのアプローチが適していますか？その場合、使用するには最高の機能は何ですか？あるいは、問題に近づくために、他にも良い方法がありますか？

（ああ、今のSQL Server 2005上で実行されているが、それは場合に役立ちます私たちはすぐに、2008R2に移動されます。）

Answer 1

私は私が実際にCHECKSUMを信頼することを知りません。私は、人々が2つの異なる行が衝突を起こしたことを文書化した多くのケースを見てきました。行が変更された（または宛先にまだ存在していない）ことを知りたいだけですか？ ROWVERSIONを使用する可能性を破棄しましたか？両方の場所でデータを更新する可能性はありますか？

すぐにSQL Server 2008 R2に移行しているので、Change TrackingやChange Data Captureのような、すでに存在する他の方法について考えましたか？ （Comparison here）。この問題を解決する他の方法もありますが、どの行が変更されたかを気にする必要はありませんが、これは最終目標に依存します。私が作業していた古いシステムでは、一次データの変更を別々のスキーマにまとめて、データが到着したときにswitcherooを実行します。もちろん、すべてのデータがソースで更新されました。宛先が数分遅れても問題ありませんでした。しかし、それはソースと目的地の間のデルタを計算するという面倒を防ぎました。