多个类似查询访问答案

【问题标题】：multiple like queries access多个类似查询访问
【发布时间】：2016-02-28 11:32:01
【问题描述】：

我正在使用 Access。
Szenario
在工作中，我有一个包含大约 300k 行的表，它使用相关信息（名字、姓氏、城市、“街道 + 街道编号”、邮政编码）将人员 ID 定义为房屋 ID。每个人可以住 n 栋房子，每栋房子可以住 n 个人。

当我被不同的人拜访时，我得到一张桌子。这张表是由人填写的，所以里面没有ID，不幸的是经常有拼写错误和信息丢失。它应该包含“名字”、“姓氏”、“街道和 Nr”、“城市”、“邮政编码”。

要整合数据，我需要人员的 ID。为了解决拼写错误问题，我想建立一个表格，让我得到按“匹配优先级”排序的结果。

手工填写的表格名为 tbl_to_fill，其中有空的 Person-ID 行、索引的自动编号和名字、姓氏、街道和编号、城市和邮政编码。包含关系信息的表称为tbl_all。

因此，如果我找到从 tbl_to_fill 到 tbl_all 的“First Name”、“Last Name”和“Postal Code”或“First Name”、“Last Name”、“Street & Nr”的完全匹配（使用连接查询） ", "City" 它得到 "matching priority" 1. 如果我找到一个完全匹配的只有 "Last Name", "Postal Code" 或 "Last Name", "City", "Street & Nr" 我得到一个 "matching优先级” 2. 还有几个级别。

接下来是棘手的部分：
现在我从“tbl_to_fill”构建了一个“tbl_filter”，其中包含经过调整的信息：街道号码被删除，常见的拼写错误被替换为'*'（例如德语名称中的常见拼写错误：ph - f，如 Stefan 和 Stephan )，城市名称在最后一个空格 " " 之后被缩短。

使用此表，我查找与上述相同的条件，但使用"LIKE '*' & tbl_filter.Field & '*'" - 查询。他们获得与上述相同的匹配优先级+ 10。现在这些 join 查询和 Like 查询都通过联合查询聚合起来，我们称这个查询为 001 quni All rows。

我让它完全按照我想要的方式工作，但每次运行最后一个查询时都需要 AGES。

我的问题
有人做过类似的事情吗？我该怎么做才能加快流程？

由于我的许多匹配条件都希望 First Name 和 Last Name 适合，然后更多，我是否应该首先通过 make 表从“tbl_all”中仅提取匹配的行，然后运行相应的查询？
我应该使用正则表达式而不是对包含由“-”连接的所有信息的字段进行类似查询吗？有没有更好的方法来分配这些优先级？也许通过 IFF 函数进行一次查询？

Select ..., matching_priority = IFF(tbl_all."First Name" =  tbl_to_Fill."FirstName",1,
    IFF(...)
)
From tbl_all;

我是一个自力更生的访问开发人员，所以我经常不知道哪种方法最优化。我经常使用 VBA 并且不会回避它，所以如果您通过 VBA 找到了解决方案，请告诉我。

【问题讨论】：

标签： ms-access vba ms-access-2010

【解决方案1】：

如果您要使用模糊文本搜索，我认为您可能会稍微简化您的方法。执行此操作的常用方法是使用 Levenshtein 距离，或将一个字符串转换为另一个字符串所需的更改次数。 Levenshtein 的一个很好的实现在这里：

Levenshtein Distance in Excel

通过这种方式，您可以找到与城市、街道、名字、姓氏等最接近的匹配项。您甚至可以设置“合理”的限制，例如 Levenshtein > 10 可能为“不合理。”我扔了 10 个，但它会因您的数据而异。

一些优化说明：

基于您有 300,000 行的事实，我什至可以说您仍然需要稍微缩小结果范围。为每场比赛读取所有 300,000 条记录是不合理的。例如，如果您有状态（我认为您没有），那么合理的限制是说状态必须匹配。这会将您的 300,000 降低到一个低得多的数字。您可能还想假设姓氏的第一个字母必须匹配。这将进一步缩小范围。等等等等。
如果可以，我会使用实际的 RDBMS 而不是 Access 来存储数据并让 DB 服务器完成繁重的工作。特别是 PostgreSQL，通过扩展提供了很好的模糊搜索功能

【讨论】：

【解决方案2】：

我在类似情况下做过的一件事是提取姓氏的前几个字符，名字的前一个或两个字符，以及邮政编码，并将其从两个表写入临时表，然后对截断的表进行匹配查询。在对要提取的字符进行一些修改后，我通常可以在速度和误报匹配之间找到一个平衡点，然后让人工审查结果列表。速度差异可能很大 - 如果不是将 Schermerstien、Stephan 与 Schermerstien、Ste*an 匹配，而是将 Scher、St 与 Scher、St 匹配，则可以看到处理优势。但它只有在表格之间有一个小的交叉点并且您可以容忍人工审查步骤时才有效。

【讨论】：