1

People のテーブル (name、dob、ssn など) NewRecords
のテーブル(name、dob、ssn)どのNewRecordsがどのPeopleにも一致しない かを判断するクエリを書きたい(フラグを設定する更新クエリ) NewRecordsテーブル内)。

具体的には、 Peopleのすべてのレコードについて、名、姓、および ssn の間のレーベンシュタイン距離が 2 より大きいNewRecordsを見つけたいと考えています。(つまり、人物の名、姓、および ssn がすべてPeopleのものと異なるため、一致しない可能性があります)。

T-SQL にユーザー定義のレーベンシュタイン関数レーベンシュタイン距離を追加し、最大許容距離の追加パラメーターを追加する最適化を既に追加しています。(計算されたレーベンスタインが許容される最大値を超えた場合、関数は早期に終了します)。ただし、テーブルが大きいため、クエリには依然として許容できないほど長い時間がかかります。

スピードアップするにはどうすればよいですか？最適化とパフォーマンスについて考え始めるにはどうすればよいですか? どの時点で SQL Server の内部を掘り下げる必要がありますか?

update NewRecords
set notmatchflag=true
from 
newRecords elr
inner join People pro
on 
dbo.Levenshtein_withThreshold(elr.last,pro.last,2)>2 and 
dbo.Levenshtein_withThreshold(elr.first,pro.first,2)>2 and
elr.ssn is null and
elr.dob<>pro.dob
4

3 に答える 3

3

テーブルの構造とデータの種類を正確に知らないため、これが機能するかどうかは 100% 確信が持てませんが、とにかく試してみてください!

テストするときは、最初に SQL 実行計画を確認します。通常、最も時間がかかるセクションがいくつかあります。そこから、インデックスがどこで役立つかを判断できるはずです。

私の直感はあなたの機能であり、物事の外見から多くのことを呼んでいますが、実行計画がそうであるかどうかを判断することを願っています. その場合は、CLR ストアド プロシージャが適している可能性があります。

于 2013-04-29T13:53:54.030 に答える
1

真の値をスキップするため、再度実行するとそれらは処理されません。
その距離は高価です - 最初にチャンスがないものを排除してみてください.
長さが 2 以上異なる場合、距離が 2 以下になるとは思えません。 

update NewRecords
set notmatchflag=true
from  newRecords elr
inner join People pro
  on notmatchflag = false
 and elr.ssn is null 
 and elr.dob <> ro.dob
 and dbo.Levenshtein_withThreshold( elr.last, pro.last,2) > 2  
 and dbo.Levenshtein_withThreshold(elr.first,pro.first,2) > 2
于 2013-04-29T15:15:26.423 に答える