【发布时间】：2013-10-04 19:35:40
【问题描述】：
我正在尝试将用户提供的邮政地址数据与地址参考数据集进行匹配。我想索引两个数据集并加入索引字段。在理想情况下，这将使用由完整地址组成的密钥（例如，WHERE REF_ADDR = INPUT_ADDR 将给出100 W Main St, Springfield, OH 45502 = 100 W Main St, Springfield, OH 45502）。当然，地址很少是完美的，所以我有一个脚本可以使用模糊逻辑来适应差异。但是，由于此脚本非常慢，因此我想减少在使用之前尝试匹配过程的参考数据集中的候选者数量。为了找到所有潜在的候选人，我打算创建一个从各个地址组件派生的索引键，用于加入。问题是，仅靠一个键无法捕获所有可能的候选者。我可能需要创建多个索引键才能捕获所有候选者。
例如，地址100 W Main St, Springfield, OH 45502 的100 WMNST 455 形式的索引键在大多数情况下都很好，但可能有任意数量的地址错误不会被这样的键捕获。为了适应匹配过程将识别的所有潜在错误，我可能需要实现至少几个索引键以进行连接。
我想知道是否有人对处理此问题有任何建议。参考数据集由 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
【问题讨论】：
-
如何创建一个单独的表，其中包含每个可能匹配的行，链接回原始表的一条记录。当您查询匹配项时，您使用其单个索引查询此表。
-
可能的匹配必须来自参考数据。您是说从参考数据中的可能匹配项生成一个表，然后使用此表而不是包含连接的用户提供的地址数据的参考数据执行匹配尝试？这会提高性能吗？
-
这就是我的想法——所以当你将
123 E Main插入到真实表中时，你会插入123 Main、123 East Main，但是在你的新表中存在许多其他可能性——这些记录中的每一个都有一个与您的原始记录相对的 FK。当您查询时，您将查询新表。我不确定性能会不会很好，但这将是一个简单的解决方案，因为单个列上有一个简单的索引，并且检索可能匹配项的所有逻辑都提前完成，而不是即时完成在select查询期间。 -
这是有道理的。我会考虑到这一点。谢谢乔！