3

重複した連絡先レコードを判断する一連のビジネス ルールを開発しました。これらのルールの基本は、最初に同じ名前をチェックし、次に電話番号、電子メール、電話番号などの他のフィールドを比較することに集中しています。

問題は、ごく一部のレコードのみがキャプチャされ、自動的にスクラブ/マージされることです。

より多くのレコードをキャプチャするために、連絡先名に入力ミスを含めたり、チェックしたりしたいと思います (例: Michael=Micheal)。

より正確な結果を返すために、タイプミスをチェックするために使用できる優れた機能はありますか? 2 つの文字列を比較して 1 文字の違いを探す関数がうまくいくと思います。

4

1 に答える 1

4

ほとんどの文字列類似性測定アルゴリズムは計算集約型であり、当面のジョブの量によっては、T-SQL はパフォーマンスの点で適切な選択ではないことに注意してください。

文字列の類似性測定自体の代わりに、ハッシュ関数、特に単語の主要な「構造」を保持するものを検討してください。ハッシュ コードの利点は、入力として1 つの文字列のみを使用して 1 回だけ計算され、単純な等価述語を使用して [TSQL] フィルターで使用できることです (可能な参照文字列ごとにアルゴリズムを実行することを意味する類似度測定とは異なります)。 )。もっともらしいハッシュ コードの提案はSOUNDEXです。これは、個人名や会社名の典型的なバリエーションに特に適していて、TSQL 関数として「ネイティブに」実装されています。

名前フィールドの個々の単語ごとに soundex コードを計算することがおそらく望ましいでしょう。たとえば、「Charles Darwin」のような入力に対して 2 つのコードを生成し、「Jean Jacques Rousseau」などに対して 3 つのコードを生成し、パフォーマンスを向上させるには、姓と名を区別する方法を見つけて、フィルター条件を容易にします。

文字列の類似性メソッドを使用することを好む場合は、レーベンシュタイン距離またはRatcliff/Oberhelp測定のいずれかが、タイプミスなどの小さなバリエーションを処理するのに適していることがわかりました。Soundex と同様に、単語を個別に処理することを検討することもできます。これにより、特定の名前エントリに対して複数の値を処理することが難しくなりますが、名前の典型的な状況をより積極的に処理することができます。次に姓、その他のインスタンスを逆の順序で (または、名前の一部を省略または省略して) 表示します。

于 2013-02-19T04:26:44.907 に答える