通过将街道地址分成多个单独的列可以解决哪些问题？

我们有一个团队为软件开发人员设计表格和关系。在我们的组织中，他们对执行3NF标准化非常严格-坦白地说，鉴于我们的组织规模以及需求或客户随时间的变化，我同意。我对他们的设计决定背后的原因只有一个不清楚的地方：地址。

虽然这主要针对美国的地址，但我认为这可以适用于任何这样做的国家。地址的每个部分在地址表中都有自己的列。例如，以这个肮脏的美国地址为例：

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

它会像这样在数据库中拆分：

• 街道号：485
• 街道分数：1/2
• 街道定向：N（北）
• 街道名称：史密斯
• 街道类型：ST（街道）
• 街后：SW（西南）
• 城市：芝加哥
• 州：IL（伊利诺伊州）
• 邮政编码：11111
• 邮政编码：2222
• 国家（假设为美国）
• 注意：Jane Doe
• 邮政信箱：NULL
• 居住类型：APT（公寓）
• 居住人数：300B

并且还会有其他几列与乡村路线和合同路线相关。此外，我们的特定应用程序可能会包含一些国际地址。数据建模人员表示，他们将添加特定于国际地址的列，即通常的第1行，第2行字段。

起初我以为这太过分了。反复进行在线研究是指使用地址行1、2、3和可能的4，然后划分城市，地区和邮政编码。对于这种粒度很有用的新应用程序，我们确实有一个用例。我们必须验证用户没有创建重复业务，并且检查地址是验证之一。我们可以使其与地址线1和2一起使用，但这会更加困难。

对于我们的特定应用程序，我们需要为企业和个人存储多种地址（实体地址，邮件地址，运输地址等）。我们可能需要生成可打印的套用信函，但到目前为止尚未讨论该要求。

我们组织中的应用程序还需要支持其他一些功能：

• 审核（带有完整的历史记录表）
• 打印邮件标签
• 生成打印表格
• 报告（针对国家和地区政府）

虽然我们的应用程序可能无法像其他应用程序那样做所有事情，但是将地址拆分为多个组件是我工作的企业标准。无论我们的应用程序是否将从中受益，我们都被迫这样做。

半相关的StackOverflow问题：一个好的地址解析器在哪里被关闭，但是它说明了解析地址有多困难。

为了让我更好地了解他们的设计决策，并向我们的客户推销该想法...

将街道地址分为几列可以解决哪些问题？

对于实施了这样的系统的任何人，如果他们遇到了问题，就会获得加分。

拆分可以解决的问题包括

验证名称的任何一部分都可以与主列表进行比较。那些不匹配的可以被拒绝。邮政编码/邮政编码是一个明显的例子。这些由独立机构发布和维护。唯一有效的是由该机构颁发的证书。

排序和选择我已经看到了一些情况，如果将邮件交给已经组织了一定程度的递送服务，则邮政费用会减少。拥有相应的列会产生切实的商业价值。

分析以地理分层的方式了解订单的去向可能会很有用。这可能会推动销售计划，产品开发或佣金支付等。

代码重复通过使组织中的所有应用程序都使用相同的数据模型（最复杂的使用者），可以在企业范围内采用单个代码库并保持一致。可以避免无休止的重复头发分裂，或者至少将其分配给螺旋桨头。由组织的不同部门持有的地址可以一致地更新。可以提高客户服务和满意度。开发工作可以集中于系统的独特，高价值的部分。

法律问题法律和税收因司法管辖区而异。通过分别捕获详细的地址值，可以更轻松地将交易数据与合规性要求进行交叉引用。

复制通过将一个元素移到下一行或对某些部分重新排序，可以很容易地欺骗以文本形式保存的地址。完全解析的地址更易于比较。这可能是一个简单的数据质量问题，或者如果多个空壳公司向同一交货地址下达大笔订单，或者使用信用卡在短时间内将货物交付到多个分散的地点，则可能会涉及法规遵从或信誉问题。

单独存放的格式化部件可以按照当前需要的任何方式组合。如果说长而薄的印刷标签变得便宜，则可以重新格式化以使用它们。

当然，这些都不适用于任何特定的应用程序。这种类型的数据在收集时比在后期分析中要容易得多，在源头进行解析和验证。因此，即使是YAGNI，最好还是花很少的成本预先投入额外的精力，并可能节省大量的未来费用。

最后，我不会忽略人为因素。数据模型由数据建模人员生成。这就是他们所做的。那是他们的职业。他们不会告诉您将其转储到BLOB中，对吗？

我花了7年的时间为一家出版公司开发软件，而我们所解决的最棘手的问题之一就是解析订阅列表中的街道地址。这是地址分成不同的领域是有用的，但你永远无法，EVER设计出的地址格式和人的大脑可以设计的组件每一个可能的病理像差。

每个地方都有其怪癖，而这只是在美国。抛出其他国家/地区，对于任何想解析每个地址的方法来说，事情很快就会变得难以处理。仅举两个例子：

在西班牙，街道编号始终位于街道名称和逗号之后，并且许多地址包含序号（例如1°或3ª）的序号，以及“ left”（“ Izda”的缩写，表示左门后您上楼梯），“右”（“ Dcha”）或其他可能性。现在，将这个古怪性乘以具有不同历史习俗的地址的不同国家和地区的数量...（日本，英格兰乡村，韩国或中国）。

在俄勒冈州波特兰市，有NS和EW轴将城市划分为NW，NE，SW和SE象限（以及N个“象限”，但我离题了）。NS街道从该轴开始以东西方向递增编号，而EW街道上的地址则由NS街道编号决定，即该数字的“百个街区”（即，在EW街道上第11和12大街之间的房屋会有一个数字像1123）。美国地址的相当标准的东西。

几乎每隔一段时间，你碰上了波特兰地址像0205 SW内布拉斯加州圣。前导零？WTF？我integer的房子编号栏里有。

建立网格后，NS轴由Willamette河定义。河流以东的一切为东北或东南，河流以西或西北。随着城市向南发展，他们遇到了一条不便的事实，即河流向东蜿蜒，因此将轴线向南投影时，您会遇到这个有问题的区域，该区域位于河流的“西”侧，但位于轴线的东侧。解决方案是添加一个前导零，实际上是一个负号，数字从轴线向东递增。

如果我是你，我会放弃设计最终系统的希望。您无法涵盖所有​​可能性，而随着人类进入未开发的土地，将会创造出新的可能性。

对于美国地址，请看一下USPS在地址标准化方面已经做了些什么，并记住将其house_number列为a varchar。在查看时，请弄清楚如何解析1634 EN Fort LaneAve。

对于世界其他地方，我可能会尝试提取其他字段以覆盖可能出现的80-90％的数据，并提供一组未解释的字段，这些字段在必要时可以处理其他所有内容。即，如果您的解析器无法处理地址，则将其保存为未解析并进行标记。如果您确实要解析一个地址，请确保您记得找到各个字段的顺序，以便可以将其重新组合成可交付的内容。

我要说的是，最重要的领域将是邮政编码，但是即使在很多地方也没有做到这一点。

祝好运。这可能是一个有趣且令人沮丧的工作，但是保持头脑清醒的关键是知道何时退出尝试，仅存储未解析的输入，或将与原始输入部分解析的输入作为备份。

像所有设计问题一样，有一个非常严格的“取决于”。这取决于您的数据故事-如何收集数据，如何使用数据，如何更新数据等。我的所有评论都应作为讨论重点，而不是方法回答。

听起来*您可以通过使用地址验证服务而受益，而不是尝试自己构建一个。尽管它们很昂贵，但许多此类服务都具有可观的邮寄折扣。

当然，对于某些数据故事，这里有一个折衷方案。您可以保留解析出的地址片段，并为组合的地址创建一个计算列（可能是一组列）。这是一个实现答案，暗示了所有正常的警告。

我已经实现了解析的地址设计。对于数据质量和数据处理需求，我们绝对需要这样做。但这是一家具有物理地址，邮政地址，虚拟地址等的公司。

可能出现的另一个问题是，不同的邮政服务要求相同的信息以不同的格式/顺序/等呈现。因此，对零件进行建模可以支持以各种格式和布局显示相同的信息。

最后，您不必具有国际业务运营就可以支持国际数据。甚至美国公司也需要支持国际地址。假设您永远都不会拥有它，这是一个巨大的数据错误。客户搬家，供应商更改总部，即使他们有美国总部，供应商联系信息也可以是国际性的。即使您当前的系统犯了这个错误，您也不想将这一错误推向前进。

我强烈推荐Graham Rhind撰写的著作和博客。他是有关各种地址以及与之相关的取舍方面的数据领域专家。

_{*我在这里所说的只是一个概括。对于设计解决方案，我有很多问题需要帮助，可能需要花费几个小时的时间。也可能有一些图片和一些数据分析。然后是关于地址的许多非常古怪的数据故事。}

完全忽略了正确解析人们提供的无法预测的乱码的巨大挑战，解析的好处是它为您提供了用于分组和排序的维度。例如，邮政编码。但是，解析一个特定的维度并没有收益，直到您需要对该维度进行分组或排序为止。

无论如何，地址是什么？您可以很好地说明它是一个位置标识符，但在情况上也可以很好地说明它是交货说明-“从水泥厂下街”。在澳大利亚，人们认为邮政编码是位置标识符，但不是，它们是路由代码-交货说明。4702是Rockhampton Mail Centre，这是一个主要的配送节点，服务于从海域延伸到内陆300公里的采矿小镇Emerald的地区。

如果您想确定位置，那么Bing和Google可以直接将未解析的字符串地理编码为GPS坐标，该GPS坐标可以与未解析的字符串一起存储在一个小的简单表格中。他们使用唯一的通用方法来获得始终如一的良好结果：排名加权的部分匹配与经过验证的庞大数据库。

如果您需要交货指示，仍然建议保留未解析的字符串，因为它可能包含任何东西。

注意，在两种情况下，我都建议保留未分析的字符串。那是因为

• 它本身就很有用
• 有一天你会想出如何解析它
• 几天后，您将弄清楚如何正确解析它
• 这永远不会结束

可以说地址始终是传递指令，至少包含一个位置标识符。一封写给“ Emerald 4702的Main Main 123”的信中编码了三个位置：Rockhampton北部的RMC，Emerald和街道地址。罗克汉普顿邮局只会将其发送给RMC。RMC将其发送到Emerald邮局，Emerald邮局希望知道在哪里可以找到Main Main 123。

我曾经在荷兰实施过这样的系统。事实是，这类信息可能以比您想象的更多的方式改变。重命名街道，合并城市，依此类推。能够在不将地址解析为单个字符串的情况下更新此类信息真是太好了。

分隔邮政编码/邮政编码，建筑物名称，道路名称可能很有意义。但是，当您开始添加“城镇”，“区域”等时，与仅第1行，第2行等相比，它就变得可疑了。问题是，即使我和我的妻子也无法就我们所居住的城镇的名称达成共识！是将“村庄”名称放置在城镇区域中，还是将其放在道路名称下方的行中，而将本地城市放置在城镇区域中？（如果您称他们居住的是村庄而不是城镇，则有些人会被冒犯，而如果您称其为城镇而不是村庄，则居住在同一位置的其他人将会受到冒犯！）

因此，尝试做任何花哨的操作都不会比您使用的地址验证系统好。但是情况变得更糟。在英国，所有地址都应有邮政编码，但是直到房屋盖好后的某个时间才分配邮政编码。因此，系统必须允许打破关于地址的所有规则！

除了在其他答案中已经提到的问题外，在某些语言中（尤其是日耳曼语），街道名称也很复杂。例如，在许多德国城镇中，通常都有一条“ Bahnhofstrasse”，即通往火车站的街道（“ Bahnhof”是指铁路/火车站，“ Strasse”是指街道）。当然，您可以将这两个组件分离开来，但是现在，如果您想（以编程方式）将它们放回一起，就会遇到变形问题。

或者，在“浪漫”或拉丁语中，您经常使用“ Rue de la Pais”或“ Boulevard desChamps-Élysées”形式的街道名称。现在，您有了一个介词（“ de”）和一个定冠词（“ le”或“ la”），它们可以组合在一起。它们代表街道类型或街道名称的一部分吗？（您可能需要将它们存储在某个地方，否则您将再次陷入变形。）

我曾经做过这样的建模。但这对于中型大学（在美国）的住宅物业维护办公室来说是一个很小的应用程序。由于以下原因，我对地址进行了非常细化：

• 该地区有些街道具有相同的名称，但街道的“类型”不同（例如，“伍兹大街”与“伍兹法院”）。
• 用户希望能够优化维护工作，例如，如果在同一块上有两个或多个服务请求，这些请求可以同时处理。
• 用户希望能够关联同一建筑物中不同单元（公寓）之间的问题-例如，如果有多于一间公寓报告低温或热水不足。

...以及其他我不再记得的原因。（这是在1980年代后期。）

再说一次，这仅是有道理的，因为要处理的地址（和地址格式化规则）数量相当少。由于其他答案中已经给出的原因，即使是仅限于美国地址，我也不认为这种方法可以扩展。