run_config_128 /事実かどうかレコードが存在する決定する必要がディメンションを更新してください。これは通常、主要なビジネス（自然キー）ディメンションで見て行われます。見つからない場合は、それが新しいレコードであり、それは、挿入をする必要があります。これが見つかった場合は、それがレコードを変更した（タイプ1）または更新される新しいレコードが（タイプ2）を作成する必要があります。私はexpirementerenは、ルックアップを加速することのプロセスにされています。ここに私の所見これまでのところ。

高速varchar型以上の整数値のルックアップを行います。すべてのビジネスキーは私がvarcharフィールドとしての私のデータウェアハウスでは、しばしば2つのフィールドの組み合わせを検討する。これは、このような意思決定ポイントは、商品を：プレビュー追加する場合、将来的にミスを避けるためです：
- DimElement：会社コード+要素コード
- DimUitvoerCodeは：会社コードの実行可能コードを検索する

我々は、ソースキーにディメンションに直接に関連することができますし、フィールドには、たとえば、保存すると、100_101（会社コード、コンポーネントのコード）。我々は、ルックアップ、それらの2つのフィールドで呼び出しを行うことはできません。私の好みなので、キーがソースからたどることができるアンダースコアが続く、これらの2つのフィールドをコンパイルすることです。

追加の可能性はチェックサム/ハッシュを生成2つのフィールドを超えている。利点は、検索が1つだけフィールドは、このキーをリソースの名前で行われますは汎用的です。我々は常にソースハッシュのキーの例を呼び出すすべてのリソースが同じ型、同じ長さです。

T - SQLの関数をチェックSSISの米海軍
チェックサムは、4バイトの整数フィールドとその存在迅速に検索することができます行われることです。チェックサムが良い一部の列を持っていないですがチェックサムを重複が（実績）が発生する可能性がありますので、生成されます。の生成ビジネス拠点のチェックサム信頼されていません。

私は、（テーブルの上に会計プログラムからなど）私は多くのチェックサムを複製するビジネスキーを形成する3つの列にCRC32のを生成する場合。

AS番号のSELECTは、COUNT（*）
から
（セレクトBINARY_CHECKSUM（cmpcode、doccode、DocNum）として
からdbo.oas_dochead_REG dhをとして
）はX
GROUP BYを
（*）> 1数が足りない

SSISのコンポーネント
http://www.sqlis.com/post/Checksum-Transformation.aspx

チェックサムはコミュニティからコンポーネントをSSISのチェックサムの種類をサポートします。

CRC32の
1つは、CRC32のです。私はこれが唯一の重複を作成し、テストしているため、信頼性の高いされていません。これは、チェックサムの生成列の上で複数の列の両方が発生します。

Frameworkchecksum
frameworkchecksum技術が作成さ複製します。私は20万レコードと、それをテストしてみた2つの生成重複をした。

オリジナル
最後のポストは、8つの重複のチェックサムをテストし、適していません。

結論
それはvarcharフィールドであるため、T - SQLのコースからMD5ハッシュ関数は、私が使用する、それだけで約50％遅くなります。チェックサムが整数フィールドです。その場合、私は同様に重要なソースのルックアップを行うことが、これも小さいです。

更新日：
私たちの倉庫では、LookupHash寸法バイナリ（20）分野での使用します。利点は、一般的な名前のソースキーが作成されますです。ルックアップはsurrogatkeyあなたが今フィールドLookupHashに行うことができます事実を移入を取得します。もう一つの利点は、バイナリフィールドのインデックスが良いです。

一言で言えば：ときにディメンションが常にLookupHash列が生成されます作成タイプのバイナリ（20）。次の事実からも同じバイナリ（20）と同じ列には、結果がディメンションのと同じですに変換キーのJOINで行う。その後、すぐにsurrogatkey得ることができます！