Sql server SQL模糊匹配

希望我没有重复这个问题。在这里发布之前，我在这里和谷歌做了一些搜索

我正在使用启用全文的SQL Server 2008R2运行eStore

我的要求,，

有一个产品表，其中有产品名称、OEM代码、该产品适合的型号。都是文本

我创建了一个名为TextSearch的新专栏。它将产品名称、OEM代码和该产品适用的型号的值串联在一起。这些值以逗号分隔

当客户输入关键字时，我们在TextSearch列上运行搜索以匹配产品。请参阅下面的匹配逻辑

我使用混合全文和正常喜欢做搜索。这给出了更相关的结果。返回了在临时表和distincts中执行的所有查询

匹配逻辑

运行以下SQL以使用全文获取相关产品。但是@关键字将被预处理。表示“CLC 2200”将更改为“CLC*和2200*”

从包含的dbo.Product中选择Id（TextSearch，@Keywords）

另一个查询将使用normal like运行。因此，“CLC 2200”将被预处理为“TextSearch like%CLC%和TextSearch like%2200%”。这仅仅是因为全文搜索不会在关键字之前搜索模式。例如，它不会返回“pclc 2200”

从dbo.Product中选择Id，其中TextSearch类似于“%clc%”，TextSearch类似于“%2200%”

如果步骤1和2未返回任何记录，将执行以下搜索。我对值135进行了微调，以返回更多相关记录

从dbo.Product中选择p.id作为p内部连接FREETEXTTABLE（Product，TextSearch，@Keywords），作为p.id=r.[KEY]上的r，其中r.RANK>135

以上所有组合都以合理的速度运行，并返回关键字的相关产品

但我正在寻找进一步改善时，没有发现任何产品

比如说，如果客户寻找“CLC 2200npk”，而该产品不在那里，我需要在“CLC 2200”附近展示下一个

到目前为止，我尝试使用Soundex（）函数。购买计算TextSearch列中每个单词的soundex值，并与关键字的soudex值进行比较。但这样返回的记录太多，速度也太慢

例如，“CLC 2200npk”将返回“CLC 1100”等产品，但这不是一个好结果。因为它不接近CLC 2200npk

还有一个好的。但它使用CLR函数。但是我不能在服务器上安装CLR函数

所以我的逻辑应该是

如果未找到“CLC 2200npk”，则在“CLC 2200”旁边显示 如果未找到“CLC 2200”，则在“CLC 1100”旁边显示下一个关闭位置

问题

是否可以按照建议进行匹配

如果我需要做拼写更正和搜索，什么是好方法？我们所有的产品清单都是英文的

是否有任何UDF或SP与我的建议等文本相匹配

---

谢谢。

一个相当快速的特定领域解决方案可能是使用SOUNDEX和两个字符串之间的数字距离来计算字符串相似性。只有当你有很多产品代码时，这才真正有帮助

使用下面这样一个简单的UDF，您可以从字符串中提取数字字符，这样您就可以从“CLC 2200npk”中提取2200个，从“CLC 1100”中提取1100个，这样您就可以根据每个输入的SOUNDEX输出以及每个输入的数字分量的接近度来确定接近度

CREATE Function [dbo].[ExtractNumeric](@input VARCHAR(1000))
RETURNS INT
AS
BEGIN
    WHILE PATINDEX('%[^0-9]%', @input) > 0
    BEGIN
        SET @input = STUFF(@input, PATINDEX('%[^0-9]%', @input), 1, '')
    END
    IF @input = '' OR @input IS NULL
        SET @input = '0'
    RETURN CAST(@input AS INT)
END
GO

就通用算法而言，根据数据集大小和性能要求，有几种算法可以帮助您获得不同程度的成功。（两个链接都有可用的TSQL实现）

• -此算法将以速度为代价，提供比soundex更好的匹配，但它确实有助于拼写纠正
• -这将计算将一个字符串转换为另一个字符串所需的按键次数。例如，从“CLC 2200npk”到“CLC 2200”是3，而从“CLC 2200npk”到“CLC 1100”是5

这是一篇有趣的文章，它将两种算法应用在一起，可能会给你一些想法

好吧，希望这能帮上一点忙

---

编辑：是一个更快的部分Levenshtein距离实现（阅读文章，它不会返回与正常结果完全相同的结果）。在我的125000行测试表中，它运行时间为6秒，而我链接到的第一个测试表运行时间为60秒。

Levenshtein Distance似乎在按搜索列重建时给出了很好的结果。它还能容忍一些拼写错误。给人印象深刻的缺点是，它似乎需要一些时间来运行。我希望改进这一点。还检查了您的ExtractNumeric UDF，但这并没有产生足够的变量来匹配精确的。标记为答案的。Jeyara.刚刚编辑了一个更快的Levenshtein距离实现，这将有助于提高运行时间。感谢改进的Levenshtein距离实现。Levenshtein距离函数如果作为CLR函数实现，性能可能会更好。例如，我在C#中创建了一个Damerau-Levenshtein函数，在SQL Server中用作CLR函数。它根据搜索字符串计算125000个表行的距离，总时间不到一秒。最后两个链接已失效！