为表连接创建多个索引以适应模糊匹配

Question

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

例如，地址100 WMNST 455的{​​{1}}形式的索引密钥在大多数情况下会很好，但是可能存在任何数量的地址错误键。为了适应匹配过程将识别的所有潜在错误，我可能需要实现至少几个索引密钥才能加入。

我想知道是否有人有任何处理此问题的建议。参考数据集由40M记录组成，用户提供的地址数据通常约为10,000条记录。简单地在地址字段上使用100 W Main St, Springfield, OH 45502和LIKE查询而不是我提议的方法会更有效吗？在后一个数据集中遇到以下变化（由脚本适应）并不罕见：

OR

Answer 1

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

你要问的是建议一些索引选项，但对我来说这不是一个正确的问题，因为随着数据在表中的增长和/或你的搜索条件变得复杂，你将被限制为很少的选项。如果架构设计本身不具有可伸缩性，那么在以后的极端数据情况下，您将无法实现更多性能改进。

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

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

在您的情况下，地址是一种很少发生完全匹配的数据。所以我想你可以跳过它，但如果你想实现它，它可以做一些改变。您可以根据需要自定义它，具体取决于您想要处理的复杂性和复杂性。 这是概念。

我们需要5张桌子。

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

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

由于我们已经准确地分离出数据，因此您可以向用户提供用户想要访问的准确数据的选项。这将减少搜索负载并批量搜索操作。

如果这是你想要的东西，请告诉我。创建虚拟数据并提出性能数字并不是什么大问题。我可以提供可能适合您的最终设计。