アーノルド・フリブルは sqlteam.com/forums で2つの提案をしました。
これは2006年からのより若いものです：
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS ON
GO
CREATE FUNCTION edit_distance_within(@s nvarchar(4000), @t nvarchar(4000), @d int)
RETURNS int
AS
BEGIN
DECLARE @sl int, @tl int, @i int, @j int, @sc nchar, @c int, @c1 int,
@cv0 nvarchar(4000), @cv1 nvarchar(4000), @cmin int
SELECT @sl = LEN(@s), @tl = LEN(@t), @cv1 = '', @j = 1, @i = 1, @c = 0
WHILE @j <= @tl
SELECT @cv1 = @cv1 + NCHAR(@j), @j = @j + 1
WHILE @i <= @sl
BEGIN
SELECT @sc = SUBSTRING(@s, @i, 1), @c1 = @i, @c = @i, @cv0 = '', @j = 1, @cmin = 4000
WHILE @j <= @tl
BEGIN
SET @c = @c + 1
SET @c1 = @c1 - CASE WHEN @sc = SUBSTRING(@t, @j, 1) THEN 1 ELSE 0 END
IF @c > @c1 SET @c = @c1
SET @c1 = UNICODE(SUBSTRING(@cv1, @j, 1)) + 1
IF @c > @c1 SET @c = @c1
IF @c < @cmin SET @cmin = @c
SELECT @cv0 = @cv0 + NCHAR(@c), @j = @j + 1
END
IF @cmin > @d BREAK
SELECT @cv1 = @cv0, @i = @i + 1
END
RETURN CASE WHEN @cmin <= @d AND @c <= @d THEN @c ELSE -1 END
END
GO
TSQLに標準のレーベンシュタイン編集距離関数を実装しました。いくつかの最適化により、認識している他のバージョンよりも速度が向上しています。 2つの文字列の先頭に共通の文字（共有プレフィックス）、末尾に共通の文字（共有サフィックス）があり、文字列が大きく、最大編集距離が提供される場合、速度の向上は大幅に向上します。たとえば、入力が非常によく似た2つの4000文字列であり、最大編集距離に2が指定されている場合、これはedit_distance_within関数は受け入れられた回答で、0.073秒（73ミリ秒）対55秒で回答を返します。また、2つの入力文字列の大きい方に一定のスペースを加えたスペースを使用して、メモリ効率も向上します。列を表す単一のnvarchar "配列"を使用し、その中のすべての計算とヘルパーint変数を実行します。
最適化：
- 共有プレフィックスおよび/またはサフィックスの処理をスキップします
- 大きい文字列が小さい文字列全体で開始または終了する場合の早期復帰
- サイズの違いが最大距離を超えることを保証する場合、早期復帰
- マトリックス内の列を表す単一の配列のみを使用します（nvarcharとして実装）
- 最大距離が指定されると、時間の複雑さは（len1 * len2）から（min（len1、len2））になります
- 最大距離が指定されている場合、最大距離限界が達成できないことが判明するとすぐに早期復帰
最適化については、TSQLのLevenshteinの my blog post と、同様のDamerau-Levenshtein実装を使用した別の投稿へのリンクでもう少し詳しく説明しています。しかし、ここにコードがあります（もう少し高速化するために2014年1月20日更新）：
-- =============================================
-- Computes and returns the Levenshtein edit distance between two strings, i.e. the
-- number of insertion, deletion, and sustitution edits required to transform one
-- string to the other, or NULL if @max is exceeded. Comparisons use the case-
-- sensitivity configured in SQL Server (case-insensitive by default).
-- http://blog.softwx.net/2014/12/optimizing-levenshtein-algorithm-in-tsql.html
--
-- Based on Sten Hjelmqvist's "Fast, memory efficient" algorithm, described
-- at http://www.codeproject.com/Articles/13525/Fast-memory-efficient-Levenshtein-algorithm,
-- with some additional optimizations.
-- =============================================
CREATE FUNCTION [dbo].[Levenshtein](
@s nvarchar(4000)
, @t nvarchar(4000)
, @max int
)
RETURNS int
WITH SCHEMABINDING
AS
BEGIN
DECLARE @distance int = 0 -- return variable
, @v0 nvarchar(4000)-- running scratchpad for storing computed distances
, @start int = 1 -- index (1 based) of first non-matching character between the two string
, @i int, @j int -- loop counters: i for s string and j for t string
, @diag int -- distance in cell diagonally above and left if we were using an m by n matrix
, @left int -- distance in cell to the left if we were using an m by n matrix
, @sChar nchar -- character at index i from s string
, @thisJ int -- temporary storage of @j to allow SELECT combining
, @jOffset int -- offset used to calculate starting value for j loop
, @jEnd int -- ending value for j loop (stopping point for processing a column)
-- get input string lengths including any trailing spaces (which SQL Server would otherwise ignore)
, @sLen int = datalength(@s) / datalength(left(left(@s, 1) + '.', 1)) -- length of smaller string
, @tLen int = datalength(@t) / datalength(left(left(@t, 1) + '.', 1)) -- length of larger string
, @lenDiff int -- difference in length between the two strings
-- if strings of different lengths, ensure shorter string is in s. This can result in a little
-- faster speed by spending more time spinning just the inner loop during the main processing.
IF (@sLen > @tLen) BEGIN
SELECT @v0 = @s, @i = @sLen -- temporarily use v0 for swap
SELECT @s = @t, @sLen = @tLen
SELECT @t = @v0, @tLen = @i
END
SELECT @max = ISNULL(@max, @tLen)
, @lenDiff = @tLen - @sLen
IF @lenDiff > @max RETURN NULL
-- suffix common to both strings can be ignored
WHILE(@sLen > 0 AND SUBSTRING(@s, @sLen, 1) = SUBSTRING(@t, @tLen, 1))
SELECT @sLen = @sLen - 1, @tLen = @tLen - 1
IF (@sLen = 0) RETURN @tLen
-- prefix common to both strings can be ignored
WHILE (@start < @sLen AND SUBSTRING(@s, @start, 1) = SUBSTRING(@t, @start, 1))
SELECT @start = @start + 1
IF (@start > 1) BEGIN
SELECT @sLen = @sLen - (@start - 1)
, @tLen = @tLen - (@start - 1)
-- if all of shorter string matches prefix and/or suffix of longer string, then
-- edit distance is just the delete of additional characters present in longer string
IF (@sLen <= 0) RETURN @tLen
SELECT @s = SUBSTRING(@s, @start, @sLen)
, @t = SUBSTRING(@t, @start, @tLen)
END
-- initialize v0 array of distances
SELECT @v0 = '', @j = 1
WHILE (@j <= @tLen) BEGIN
SELECT @v0 = @v0 + NCHAR(CASE WHEN @j > @max THEN @max ELSE @j END)
SELECT @j = @j + 1
END
SELECT @jOffset = @max - @lenDiff
, @i = 1
WHILE (@i <= @sLen) BEGIN
SELECT @distance = @i
, @diag = @i - 1
, @sChar = SUBSTRING(@s, @i, 1)
-- no need to look beyond window of upper left diagonal (@i) + @max cells
-- and the lower right diagonal (@i - @lenDiff) - @max cells
, @j = CASE WHEN @i <= @jOffset THEN 1 ELSE @i - @jOffset END
, @jEnd = CASE WHEN @i + @max >= @tLen THEN @tLen ELSE @i + @max END
WHILE (@j <= @jEnd) BEGIN
-- at this point, @distance holds the previous value (the cell above if we were using an m by n matrix)
SELECT @left = UNICODE(SUBSTRING(@v0, @j, 1))
, @thisJ = @j
SELECT @distance =
CASE WHEN (@sChar = SUBSTRING(@t, @j, 1)) THEN @diag --match, no change
ELSE 1 + CASE WHEN @diag < @left AND @diag < @distance THEN @diag --substitution
WHEN @left < @distance THEN @left -- insertion
ELSE @distance -- deletion
END END
SELECT @v0 = STUFF(@v0, @thisJ, 1, NCHAR(@distance))
, @diag = @left
, @j = case when (@distance > @max) AND (@thisJ = @i + @lenDiff) then @jEnd + 2 else @thisJ + 1 end
END
SELECT @i = CASE WHEN @j > @jEnd + 1 THEN @sLen + 1 ELSE @i + 1 END
END
RETURN CASE WHEN @distance <= @max THEN @distance ELSE NULL END
END
この関数のコメントで述べたように、文字比較の大文字と小文字の区別は、有効な照合に従います。既定では、SQL Serverの照合順序では、大文字と小文字を区別しない比較が行われます。この関数を常に大文字と小文字を区別するように変更する1つの方法は、文字列を比較する2つの場所に特定の照合を追加することです。ただし、特にデータベースがデフォルト以外の照合を使用している場合の副作用については、これを徹底的にテストしていません。これらは、大文字と小文字を区別した比較を強制するために2行を変更する方法です。
-- prefix common to both strings can be ignored
WHILE (@start < @sLen AND SUBSTRING(@s, @start, 1) = SUBSTRING(@t, @start, 1) COLLATE SQL_Latin1_General_Cp1_CS_AS)
そして
SELECT @distance =
CASE WHEN (@sChar = SUBSTRING(@t, @j, 1) COLLATE SQL_Latin1_General_Cp1_CS_AS) THEN @diag --match, no change
IIRC、SQL Server 2005以降では、任意の.NET言語でストアドプロシージャを記述できます。 SQL Server 2005でのCLR統合の使用 。それで Levenstein distance を計算する手順を書くのは難しくないはずです。
シンプルなHello、World！ヘルプから抽出：
using System;
using System.Data;
using Microsoft.SqlServer.Server;
using System.Data.SqlTypes;
public class HelloWorldProc
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static void HelloWorld(out string text)
{
SqlContext.Pipe.Send("Hello world!" + Environment.NewLine);
text = "Hello world!";
}
}
次に、SQL Serverで次を実行します。
CREATE Assembly helloworld from 'c:\helloworld.dll' WITH PERMISSION_SET = SAFE
CREATE PROCEDURE hello
@i nchar(25) OUTPUT
AS
EXTERNAL NAME helloworld.HelloWorldProc.HelloWorld
そして今、あなたはそれをテスト実行することができます：
DECLARE @J nchar(25)
EXEC hello @J out
PRINT @J
お役に立てれば。
レーベンシュタイン距離アルゴリズムを使用して文字列を比較できます
T-SQLの例は http://www.kodyaz.com/articles/fuzzy-string-matching-using-levenshtein-distance-sql-server.aspx にあります。
CREATE FUNCTION edit_distance(@s1 nvarchar(3999), @s2 nvarchar(3999))
RETURNS int
AS
BEGIN
DECLARE @s1_len int, @s2_len int
DECLARE @i int, @j int, @s1_char nchar, @c int, @c_temp int
DECLARE @cv0 varbinary(8000), @cv1 varbinary(8000)
SELECT
@s1_len = LEN(@s1),
@s2_len = LEN(@s2),
@cv1 = 0x0000,
@j = 1, @i = 1, @c = 0
WHILE @j <= @s2_len
SELECT @cv1 = @cv1 + CAST(@j AS binary(2)), @j = @j + 1
WHILE @i <= @s1_len
BEGIN
SELECT
@s1_char = SUBSTRING(@s1, @i, 1),
@c = @i,
@cv0 = CAST(@i AS binary(2)),
@j = 1
WHILE @j <= @s2_len
BEGIN
SET @c = @c + 1
SET @c_temp = CAST(SUBSTRING(@cv1, @j+@j-1, 2) AS int) +
CASE WHEN @s1_char = SUBSTRING(@s2, @j, 1) THEN 0 ELSE 1 END
IF @c > @c_temp SET @c = @c_temp
SET @c_temp = CAST(SUBSTRING(@cv1, @j+@j+1, 2) AS int)+1
IF @c > @c_temp SET @c = @c_temp
SELECT @cv0 = @cv0 + CAST(@c AS binary(2)), @j = @j + 1
END
SELECT @cv1 = @cv0, @i = @i + 1
END
RETURN @c
END
（ジョセフ・ガマが開発した機能）
使用法 ：
select
dbo.edit_distance('Fuzzy String Match','fuzzy string match'),
dbo.edit_distance('fuzzy','fuzy'),
dbo.edit_distance('Fuzzy String Match','fuzy string match'),
dbo.edit_distance('levenshtein distance sql','levenshtein sql server'),
dbo.edit_distance('distance','server')
アルゴリズムは、1つのステップで異なる文字を置き換えることにより、1つのストリングを他のストリングに変更するために、単にstpeカウントを返します。
レーベンシュタインアルゴリズムのコード例も探していましたが、ここで見つけて喜んでいます。もちろん、アルゴリズムがどのように機能しているかを理解したかったので、 Veve によって投稿された上記の例の1つで少し遊んでいました。コードをよりよく理解するために、マトリックスでExcelを作成しました。
画像は1000語以上を言います。
このExcelにより、パフォーマンスがさらに最適化される可能性があることがわかりました。右上の赤い領域のすべての値を計算する必要はありません。各赤のセルの値は、左のセルの値に1を足した値になります。これは、2番目の文字列が最初の文字列よりもその領域で常に長くなり、各文字の値が1だけ増加するためです。
ステートメントIF @j <= @iを使用し、@ iこのステートメントの前。
CREATE FUNCTION [dbo].[f_LevenshteinDistance](@s1 nvarchar(3999), @s2 nvarchar(3999))
RETURNS int
AS
BEGIN
DECLARE @s1_len int;
DECLARE @s2_len int;
DECLARE @i int;
DECLARE @j int;
DECLARE @s1_char nchar;
DECLARE @c int;
DECLARE @c_temp int;
DECLARE @cv0 varbinary(8000);
DECLARE @cv1 varbinary(8000);
SELECT
@s1_len = LEN(@s1),
@s2_len = LEN(@s2),
@cv1 = 0x0000 ,
@j = 1 ,
@i = 1 ,
@c = 0
WHILE @j <= @s2_len
SELECT @cv1 = @cv1 + CAST(@j AS binary(2)), @j = @j + 1;
WHILE @i <= @s1_len
BEGIN
SELECT
@s1_char = SUBSTRING(@s1, @i, 1),
@c = @i ,
@cv0 = CAST(@i AS binary(2)),
@j = 1;
SET @i = @i + 1;
WHILE @j <= @s2_len
BEGIN
SET @c = @c + 1;
IF @j <= @i
BEGIN
SET @c_temp = CAST(SUBSTRING(@cv1, @j + @j - 1, 2) AS int) + CASE WHEN @s1_char = SUBSTRING(@s2, @j, 1) THEN 0 ELSE 1 END;
IF @c > @c_temp SET @c = @c_temp
SET @c_temp = CAST(SUBSTRING(@cv1, @j + @j + 1, 2) AS int) + 1;
IF @c > @c_temp SET @c = @c_temp;
END;
SELECT @cv0 = @cv0 + CAST(@c AS binary(2)), @j = @j + 1;
END;
SET @cv1 = @cv0;
END;
RETURN @c;
END;
TSQLで2つのアイテムを比較するための最良かつ最速の方法は、インデックス付きの列のテーブルを結合するSELECTステートメントです。したがって、これは、RDBMSエンジンの利点を活用したい場合に編集距離を実装することをお勧めする方法です。 TSQLループも機能しますが、Levenstein距離の計算は、大規模な比較のためにTSQLよりも他の言語で高速になります。
その目的のためだけに設計された一時テーブルに対する一連の結合を使用して、いくつかのシステムで編集距離を実装しました。いくつかの重い前処理ステップ（一時テーブルの準備）が必要ですが、多数の比較で非常にうまく機能します。
簡単に言うと、前処理は、一時テーブルの作成、入力、およびインデックス付けで構成されます。最初の列には、参照ID、1文字の列、およびcharindex列が含まれます。このテーブルには、すべてのWordを文字に分割する一連の挿入クエリを実行して（SELECT SUBSTRINGを使用）、ソースリスト内のWordと同じ数の行を作成します（多くの行ですが、SQLサーバーは数十億を処理できます）行の）。次に、2文字の列を持つ2番目のテーブル、3文字の列を持つ別のテーブルなどを作成します。最終結果は、各単語の参照IDと部分文字列、およびその位置の参照を含む一連のテーブルです。言葉で。
これが完了すると、ゲーム全体でこれらのテーブルを複製し、一致する数をカウントするGROUP BY選択クエリでテーブルを複製に対して結合します。これにより、考えられるすべての単語のペアに対して一連のメジャーが作成され、単語のペアごとに単一のレベンシュタイン距離に再集計されます。
技術的には、これは他のほとんどのレーベンシュタイン距離（またはその変形）の実装とは非常に異なるため、レーベンシュタイン距離がどのように機能し、なぜそのまま設計されたのかを深く理解する必要があります。代替手段も調査してください。この方法では、編集距離のさまざまなバリエーションを同時に計算できる一連の基礎となるメトリックが得られるため、興味深い機械学習の潜在的な改善が提供されます。
このページの以前の回答で既に言及した別のポイント：距離測定を必要としないペアを排除するために、可能な限り前処理を試みる。たとえば、編集距離は文字列の長さから取得できるため、共通の単一の文字を持たない2つの単語のペアは除外する必要があります。または、同じWordの2つのコピー間の距離を測定しないでください。これは、本来は0であるためです。または、測定を行う前に重複を削除します。単語のリストが長いテキストに由来する場合、同じ単語が複数回表示される可能性が高いため、距離を一度だけ測定すると処理時間を節約できます。