1

我正在尝试将用户提供的邮政地址数据与地址参考数据集进行匹配。我想索引两个数据集并加入索引字段。在一个完美的世界中,这将使用由完整地址组成的密钥(例如,WHERE REF_ADDR = INPUT_ADDR将给出100 W Main St, Springfield, OH 45502 = 100 W Main St, Springfield, OH 45502)。当然,地址很少是完美的,所以我有一个脚本可以使用模糊逻辑来适应差异。但是,由于此脚本非常慢,因此我想减少在使用之前尝试匹配过程的参考数据集中的候选者数量。为了找到所有潜在的候选人,我打算创建一个从各个地址组件派生的索引键,用于加入。问题是,仅靠一个键无法捕获所有可能的候选者。我可能需要创建多个索引键才能捕获所有候选者。

例如,100 WMNST 455for address形式的索引键在100 W Main St, Springfield, OH 45502大多数情况下都是好的,但可能有任意数量的地址错误不会被这样的键捕获。为了适应匹配过程将识别的所有潜在错误,我可能需要至少实现几个索引键以进行连接。

我想知道是否有人对处理此问题有任何建议。参考数据集由 40M 条记录组成,用户提供的地址数据通常约为 10,000 条记录。与我建议的方法相比,简单地使用LIKE和查询地址字段会更有效吗?OR在后一个数据集(由脚本适应)中遇到以下变化并不罕见:

Address: 100 W MAIN
City: 
Zip: 45502

Address: 100 MAIN ST
City: SPNGFLD
Zip:

Address: 100 W MAIN STREET
City: SPRINGFIELD
Zip: 54502

Address: 100 MAIN
City: NORTHRIDGE
Zip: 45502
4

1 回答 1

2

根据您使用的数据库系统,您必须尝试查看是否可以使用任何内置功能。例如,如果您正在使用 SQL SERVER,我能想到的选项是“更改数据捕获”、“全文搜索”、“过滤索引”等……但如果您想开发自己的数据库系统,则不管可以在任何数据库系统上实现,那么这可能会让您感兴趣。

您要提出的问题是建议一些索引选项,但对我来说这不是正确的问题,因为随着表中数据的增长和/或您的搜索条件变得复杂,您将受到非常少的选项的限制。如果模式设计本身不可扩展,那么您将无法在极端数据情况下实现更多的性能改进。

我在我们的项目中创建了实现搜索的设计,即所谓的“Google like Search”,而用户开始输入文本,结果应该会出现适当的匹配文本建议。用户也可以通过设置来控制搜索类型。

我的意思是“完全匹配”、“相似匹配”、“以 A 开头”、“以 A 结尾”或“包含 A”。

在您的情况下,地址是一种很少发生完全匹配的数据。所以我想你可以跳过它,但如果你想实现它,它可以通过一些改变来完成。您可以根据要处理的复杂性和复杂性根据需要对其进行自定义。这是概念。

我们将需要 5 张桌子。

搜索表达式表说明

现在的问题是这个模式如何帮助或改进您的模糊搜索?

请注意,每个表只有 2 个具有 INTEGER 和/或 STRING 类型的 Clumns,我们可以在包含这两个列的每个表上都有聚集索引。

因为我们已经按准确性分离了数据,所以您可以为用户提供用户想要访问多少准确数据的选项。这将减少搜索负载并批量搜索操作。

如果这是您想要的东西,请告诉我。创建虚拟数据并得出性能数字并不是什么大问题。我可以帮助提出可能对您有用的最终设计。

搜索表达式表示例

于 2013-10-04T22:49:01.403 回答