9

假设我们有一张 People 表（姓名、姓氏、地址、SSN 等）。

我们想找到与指定人员 A“非常相似”的所有行。我想对 A 和表 People 中的所有行进行某种模糊逻辑比较。将有几个模糊推理规则分别在几个列上工作（例如，3 个名称模糊规则，2 个姓氏规则，5 个地址规则）

问题是以下两种方法中哪一种更好，为什么？

  1. 将所有模糊规则实现为存储过程，并使用一个繁重的 SELECT 语句来返回与 A“非常相似”的所有行。这种方法可能包括使用 soundex、sim metric 等。

  2. 实现一个或多个更简单的 SELECT 语句，该语句返回不太准确的结果，与 A“相当相似”，然后将 A 与所有返回的行（数据库外部）进行模糊比较以获得“非常相似”的行。所以模糊比较将用我最喜欢的编程语言来实现。

表 People 应该有多达 500k 行，我想每天进行大约 500-1000 次这样的查询。我使用 MySQL（但这还有待考虑）。

4

4 回答 4

4

我真的不认为有一个明确的答案，因为它取决于问题中没有的信息。无论如何，评论太长了。

DBMS 擅长根据索引检索信息。除非它专门用于此特定目的（如@Adrian 所回答），否则让数据库服务器在繁重的计算中浪费时间是没有意义的。

因此，您的客户端应用程序应委托 DBMS 检索规则所需的信息。

如果计算量很小，都可以在服务器上完成。否则，将其拉入客户端系统。

第二种方法的缺点在于从服务器传输到客户端的数据量以及要建立的连接数。因此，通常它是服务器中计算和数据传输之间的折衷。根据模糊规则的特殊性来实现平衡。

编辑：我在评论中看到您几乎肯定必须在客户端中实现代码。在这种情况下，出于维护目的，您应该考虑一个额外的标准，代码局部性，即尝试将所有相关的代码放在一起，而不是在系统（和语言）之间传播。

于 2013-04-10T19:28:19.467 回答
2

我会说你最好使用简单的选择来获得最接近的匹配，而不用锤击数据库，然后在你的应用程序层做繁重的工作。我建议这个解决方案的原因是可扩展性：如果您在应用程序层进行繁重的工作，那么您的问题是 map-reduce 样式解决方案的完美用例，您可以在节点之间分配相似性处理并获得结果比通过数据库更快地返回；另外，这样，您不会锁定数据库并减慢可能同时进行的任何其他操作。

于 2013-04-08T16:10:53.023 回答
1

由于您仍在考虑使用什么数据库 PostgreSQL 具有提供 Levenshtein 和 Soundex 函数的模糊字符串匹配模块。此外，您可能想查看此处描述的 pg_trm 模块。也许您也可以使用 soundex() 将索引放在列上，这样您就不必每次都计算它。但是您似乎过早地进行了优化，因此我的建议是使用 pg 进行测试，然后想知道您是否需要优化，考虑到您几乎有两分钟的时间运行一个查询，您提供的数字确实看起来并不多。

于 2013-04-04T00:02:03.437 回答
0

我会考虑的一个选项是在“People Talbe”中添加一个列，即该人的 SoundEx 值。

我已经使用 

Select [Column}
From People P 
    Inner join TableA A  on Soundex(A.ComarisonColumn) = P.SoundexColumn

这将返回 TableA 中与 People Tables SoundEx 列中具有相同 SoundEx 值的任何内容。

我没有在那种大小的表上使用过这种查询，但我认为尝试它没有问题。您还可以索引该 SoundExColumn 以帮助提高性能。

于 2013-04-11T13:39:25.483 回答