所以我有一些没有附加记录数据的带有姓名、地址和邮编的表；我有一个表，它完全相同，但有更多信息，当它们不匹配 100% 时，我需要一种方法来合并这些表。
如果它们不相同，我该如何匹配它们？我是 @SQL 的新手，但我知道它们在大多数情况下不会匹配，而且我不可能是唯一遇到此问题的人。然而，能够做到这一点的软件已被证明是困难的。
编写软件来做到这一点甚至比一开始就必须这样做更糟糕。
我知道我可以在 excel 中做到这一点；有点，但随着记录的数量，我证明它很难超过一百万。
我曾经在一家数据库营销公司工作（很抱歉向您发送垃圾邮件）。我们的工作是弄清楚“Robert Jones 671 Kimbrough SPFD MO 65802”是否与“Bobbie Joanes 671 Kimbrough St. Sprinfield MO 65809”相同如果我们不匹配，我们就有可能向潜在客户发送重复邮件这会让我们的客户看起来很愚蠢，同时也浪费了他们的钱。
我们的方法是将问题分解为更小的领域，并应用不同的标准来回答 A可能B。匹配规则太严格，你不会发现重复。匹配规则太松散，你会丢掉潜在客户。
我们有一个实体可以匹配的三个域：名称、联系方式、关系。仅当我们在两个域之间进行匹配时才允许匹配。
联系方式是邮件、电子邮件或电话。
第一步是标准化提供的地址。最终目标是获取您输入的地址并将其更正为USPS标准。在前面的示例中，两个地址都可能会收到邮件，但这仅仅是因为邮政承运人了解发件人的意图。真正的地址是
671 S KIMBROUGH AVE SPRINGFIELD MO 65806-3342
一旦您拥有一致的地址，地址匹配将是一个更容易解决的问题。您仍然需要担心不可更正的地址以及多租户位置（Suite 200、Apt B 等）的规则，但这是您需要与企业主一起解决的微调的一部分. 哦，尽管 +4 位数字便于交付，但不要让这些因素影响您的地址匹配逻辑。与 5 位邮政编码相比，这些更改的可能性要大得多。
要记住的另一件事是，如果您拥有当前地址数据很重要，那么人们会搬家，因此您可以获得过去 X 时间范围内的地址转发信息（NCOA - 国家地址变更）。当您搬家时，地址转发文件仅在设定的时间段内有效，并且在该窗口之后向您发送邮件的任何人都会收到退回发件人的邮件，而不是在此地址退回。在您发送邮件之前进行 NCOA 处理将确保您拥有当前地址，即使转发已过期。
我们的方法是对标准化地址（第 1 行 + 邮政编码）进行散列，并将其用作比较键。
关于电话的唯一棘手的事情是他们是否有与之相关的区号。我们在没有分隔符或格式的情况下存储它们，并且任何扩展名都是单独存储的。这归结为一个 7 或 10 位数的电话号码。如果我们有地址，通常有软件可以回填区号。当区号分裂时，通常会有一个宽限期，一个位置可以由 2 个（或更多）区号提供服务。
一般来说，电子邮件地址匹配或不匹配。当我们真的很想尝试匹配时，我们会清理我们的数据。这涉及查看域并确保它们存在，如果它们不存在则添加顶级域。如果我们看到 joan@aol，这是一个安全的赌注，他们的意思是 @aol.com 您可以用来增加电子邮件匹配的另一个技巧是当他们在地址中使用 + 时。某些提供商（例如 google）允许将 joan+superuser@gmail.com 传送到基本地址。我发现将电子邮件地址与我注册的特定站点相关联的方法很有用。如果垃圾邮件开始流入该帐户，那么我知道我可以咀嚼谁的屁股。但是，出于匹配目的，您可能可以丢弃从 + 到 @ 的内容
“名字里有什么？我们用任何其他拼写称为琼斯的人可能是同一个人”
威廉火柴皮尔
我们发现我们需要对 Names 执行两种不同类型的匹配。企业或实体名称和个人姓名。美国姓名可能有前缀（先生、夫人、博士、神父、森、军士等）、名字、中间名、第二中间名或父姓、姓氏/母姓、世代（Jr、Sr、IV ），专业/荣誉/学术（MBA、JD、PhD、esq 等）。那不是很有趣吗？
只要在各个部分中捕获了数据，通常就不会那么糟糕。否则，如果您假设您可以在空格上拆分以确定名称部分，那么您可能会得到奇怪的结果，因为我的姓氏为“de los santos”的朋友可以证明这一点。
公司名称，通常就是他们给你的。需要注意的事情是 DBA 做生意。“Soulless megacorporation LLC DBA Happy cuddly puppy preserve” 可能需要匹配“Happy cuddly puppy preserve”和/或“Soulless Megacorporation”
个人姓名匹配的第一关是soundex。它通常在 RDBMS 中可用，并且根据您的输入数据可能可以通过。soundex 的问题在于它只适用于欧洲名称的一个子集。我们使用的一种更智能的语音方法是双元音位算法。这为字符串匹配提供了更好的结果。
在我们上面的示例中，Jones 与 Joanes 的精确匹配将失败，但语音匹配应该会成功。但问题是我们有鲍比和罗伯特。没有任何想象力会使这两个听起来相似，但客户坚持认为我们缺少匹配项，因此我们添加了另一组检查以将昵称扩展回其完整值，然后重新进行比较。
在公司名称比较中，我们发现编制一个“停用词”列表很有用- 出现在名称中的无意义的杂乱无章但出于匹配目的应该被忽略（a, of, the, LLC, corp, univ, university）
我们随后收到反馈，称“简单”的拼写错误、换位或遗漏字母会导致实体不匹配。随着这个答案越来越长，我们也收到了关于公司名称匹配失败的反馈，例如“Johns used Tire barn”到“Johns mega used Tire barn”等实体。我们最终实现了一个n-gram 比较和一个标记比较算法来帮助解决这些场景。此后我与业内其他人进行了交谈，他们支持使用Levenshtein 距离来确定字符串匹配。
关系基本上是我们知道是真实的其他东西。一家公司开展了一项促销活动，销售人员因让客户填写业务回复卡而受到欢迎。我们有“John's used Tire barn”员工列表，我们需要将不完整的姓名数据关联回该参考集。我只在这里谈论完整性。对于您的问题，您将查看 Name 和 MoC 匹配项。
您实施的具体细节将取决于您的数据是什么样的，以及您想在问题上投入多少时间和金钱。
我的一般方法是将两组数据导入到您的数据库中。具有所有属性的数据是您的参考集。较小的数据集是您的候选集。在候选表上，添加一列包含您的参考集标识符。以下缺乏规范化，但这是有意的
CREATE TABLE
dbo.reference
(
reference_id int identity(1,1) NOT NULL PRIMARY KEY
, name_prfix varchar(50) NULL
, name_first varchar(50) NOT NULL
, name_middle varchar(50) NULL
, name_last varchar(50) NOT NULL
, name_suffix varchar(20) NULL
, company_name varchar(100) NULL
, address_line1 varchar(70) NULL
, address_line2 varchar(50) NULL
, address_city varchar(50) NULL
, address_state varchar(20) NULL
, address_postalcode varchar(10) NULL
, address_zip4 char(4) NULL
, phone_number varchar(10) NULL
)
CREATE TABLE
dbo.candidate
(
candidate_id int identity(1,1) NOT NULL PRIMARY KEY
, name_prfix varchar(50) NULL
, name_first varchar(50) NOT NULL
, name_middle varchar(50) NULL
, name_last varchar(50) NOT NULL
, name_suffix varchar(20) NULL
, company_name varchar(100) NULL
, address_line1 varchar(70) NULL
, address_line2 varchar(50) NULL
, address_city varchar(50) NULL
, address_state varchar(20) NULL
, address_postalcode varchar(10) NULL
, address_zip4 char(4) NULL
, reference_id int
)
第一步，直接匹配。在 Candidate 和 Reference 之间存在完全匹配的任何地方，将其记录在 Candidate.reference_id 中，现在将其排除在流程之外。
第二步，直接匹配昵称扩展和/或停用词替换
第三步，地址匹配与模糊名称匹配（双元音+ngram+最小编辑距离）
第四步，地址匹配与模糊昵称扩展和/或停用词替换匹配（双元音+ngram+最小编辑距离）
步骤 5，检查剩余的候选池以进行手动匹配
SSIS 的企业版提供模糊逻辑功能。基本上，它的作用与 TSQL 方法中列出的大致相同，而无需您将自己的框架放在一起进行名称匹配等。
SSIS 的 2012 版本还提供了数据质量服务，该服务将解决清除您的地址以及将名称分成几部分的问题。