Gre*_*rdt 26 normalization database-design best-practices address
我们有一个团队为软件开发人员设计表格和关系。在我们的组织中，他们对执行 3NF 规范化非常严格——老实说，鉴于我们组织的规模以及需求或我们的客户如何随时间变化，我同意这一点。只有一个方面我不清楚他们设计决策背后的原因：地址。
虽然这主要集中在美国的地址，但我认为这适用于任何这样做的国家。地址的每一部分在地址表中都有自己的列。例如，以这个粗糙的美国地址为例：
Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222
它会像这样在数据库中拆分：
还会有一些其他与农村路线和合同路线相关的专栏。此外，我们的特定应用程序中可能会包含一些国际地址。数据建模人员表示，他们将添加特定于国际地址的列，这将是正常的第 1 行、第 2 行字段。
起初我认为这太过分了。在网上反复搜索是指使用地址行 1、2、3 和可能的 4，然后拆分出城市、地区和邮政编码。我们的新应用程序确实有一个用例，这种粒度是有益的。我们必须验证用户没有创建重复的业务，检查地址是验证之一。我们可以让它与地址行 1 和 2 一起工作，但这会更困难。
至于我们的具体应用，我们需要为企业和个人存储多种地址（物理、邮寄、运输等）。我们可能需要生成可打印的套用信函，但目前尚未讨论该要求。
我们组织中的应用程序需要支持的其他一些东西：
虽然我们的应用程序可能不会做所有其他应用程序正在做的所有事情，但将地址拆分为多个组件是我工作的企业标准。不管我们的应用程序是否会从中受益，我们都被迫这样做。
半相关的 StackOverflow 问题：关闭的好的地址解析器在哪里，但说明解析地址有多么困难。
为了让我更好地理解他们的设计决策，并把这个想法卖给我们的客户……
将街道地址拆分为单独的列解决了哪些问题？
任何实施过此类系统的人都会获得奖励积分，因为他们遇到了问题。
小智 18
我花了 7 年时间为一家出版公司开发软件，我们解决过的最困难的问题之一是解析订阅列表中的街道地址。这是地址分成不同的领域是有用的，但你永远无法，EVER设计出的地址格式和人的大脑可以设计的组件每一个可能的病理像差。
每个地方都有自己的怪癖，这只是在美国。对于任何想要解析每个地址的方法，扔到其他国家/地区，事情很快就会变得难以管理。举两个例子：
在西班牙，街道号码总是在街道名称和逗号之后，许多地址包含一个楼层序号，例如 1° 或 3ª，以及“左”的缩写（“Izda”意思是左手门之后你上楼梯）、“对”（“Dcha”）或其他可能性。现在将这种古怪乘以具有不同历史习俗的不同国家和地区的地址数量......（日本？英格兰农村？韩国？中国？）
在俄勒冈州波特兰市，有 NS 和 EW 轴将城市划分为 NW、NE、SW 和 SE 象限（以及 N 个“象限”，但我离题了）。NS 街道从该轴开始以东和西递增编号，EW 街道上的地址由 NS 街道编号决定，即该编号的“一百个街区”（即 EW 街道上第 11 条和第 12 条大道之间的房屋将有一个编号像 1123）。美国地址非常标准的东西。
每隔一段时间，您就会遇到像0205 SW Nebraska St这样的波特兰地址。前导零？跆拳道？有我integer的房子“号码”专栏。
设置网格时，NS 轴由威拉米特河定义。河流以东的一切都是东北或东南，而河流的西边则是西北或西南。随着城市向南发展，他们遇到了河流向东蜿蜒的不便事实，因此将轴向南投影，您会发现这个有问题的区域位于河流的“西”侧，但位于轴的东侧。解决方案是添加一个前导零，实际上是一个减号，数字从轴线向东递增。
如果我是你，我会放弃设计终极系统的希望。您无法涵盖所有可能性，随着人类进入以前未开发的土地，将会创造新的可能性。
对于美国地址，看看USPS在地址标准化方面已经做了什么，记得把一house_number栏做成varchar. 当你在它的时候，弄清楚你将如何解析1634 EN Fort Lane Ave。
对于世界其他地方，我可能会尝试抽象其他字段以涵盖可能出现的 80-90% 的内容，并提供一组未解释的字段，以便在必要时处理其他所有内容。即，如果您的解析器无法处理地址，请将其保存为未解析并标记为此类。如果您确实设法解析了地址，请确保记住找到各个字段的顺序，以便将其重新组合成可交付的内容。
我想说最重要的领域将是邮政编码，但即使在很多地方也没有给出。
祝你好运。这可能是一项有趣且极其令人沮丧的努力，但保持理智的关键是知道何时停止尝试并仅存储未解析的输入，或使用原始输入部分解析作为备份。
Mic*_*een 11
可以通过拆分解决的问题包括
验证名称的任何一部分都可以与主列表进行比较。不匹配的可以拒绝。邮政编码/邮政编码是一个明显的例子。这些由独立机构发布和维护。唯一有效的是那些由该机构颁发的。
分拣和选择我见过一些案例，如果将邮件交给已经在一定程度上组织起来的递送服务，则邮资会减少。拥有相应的列会产生有形的商业价值。
分析以地理层次的方式了解您的订单去向会很有用。这可能会推动销售计划、产品开发或佣金支付等。
代码复制通过让组织中的所有应用程序采用相同的数据模型（最复杂的消费者的数据模型），可以在整个企业范围内采用单一代码库并保持一致。可以避免无休止地重复头发分裂，或者至少委托给螺旋桨头。组织不同部分持有的地址可以一致地更新。可以提高客户服务和满意度。开发工作可以集中在系统的独特的、高价值的部分上。
法律问题法律和税收因司法管辖区而异。通过单独捕获详细地址值，可以更轻松地将交易数据与合规性要求进行交叉引用。
复制通过将一个元素移动到下一行或对某些部分重新排序来欺骗作为文本保存的地址是很简单的。完全解析的地址更容易比较。这可能是一个简单的数据质量问题，或者如果多个空壳公司向同一个送货地址发出大量订单，或者使用信用卡在短时间内向许多分散的地点送货，则可能对合规性或信用产生影响。
单独保存的格式化部件可以以适合当前需要的任何方式组合。例如，如果长而薄的打印标签变得便宜，您可以重新格式化以使用它们。
当然，这些都不适用于任何特定应用。这种类型的数据在收集时比在后期分析中更容易在源头解析和验证。因此，即使是 YAGNI，最好先付出额外的努力，以降低成本和潜在的大量未来节省。
最后，我不会忽视人为因素。数据模型由数据建模人员生成。这就是他们所做的。那是他们的职业。他们不会告诉你只将它转储到 BLOB 中，是吗？
小智 9
像所有设计问题一样，有一个非常有资格的“视情况而定”。这取决于您的数据故事 - 如何收集数据、如何使用数据、如何更新数据等。我的所有评论都应作为讨论点，而不是如何回答。
听起来*您可以从使用地址验证服务中受益，而不是尝试为自己构建一个。虽然它们很昂贵，但许多此类服务都带有显着的邮寄折扣。
当然，对于某些数据故事，这里有一个妥协。您可以保留解析出的地址片段并为组合地址创建一个计算列（可能是列集）。这是一个实现答案，暗示了所有正常的警告。
我已经实现了解析出的地址设计。我们绝对需要它来满足数据质量和数据处理需求。但这是一家拥有物理地址、邮政地址、虚拟地址等的企业。
另一个可能出现的问题是，不同的邮政服务需要以不同的格式/订单/等方式呈现相同的信息。因此，对零件进行建模支持以各种格式和布局呈现相同的信息。
最后，您不需要拥有国际业务运营来支持国际数据。即使是美国企业也需要支持国际地址。假设您永远不会拥有它，这是一个巨大的数据错误。客户搬家，供应商更换总部，供应商联系信息可以是国际化的，即使他们有美国总部。即使您当前的系统犯了那个错误，您也不想继续推进这个错误。
我强烈推荐 Graham Rhind 的著作和博客。他是有关各种地址及其相关权衡的数据领域的专家。
*我在这里所说的只是粗略的概括。有太多的问题我必须帮助找到一个设计解决方案，可能需要几个小时的聊天。可能还有一些图片和一些数据分析。然后是很多关于地址的非常古怪的数据故事。
完全撇开正确解析人们提供的不可预测的胡言乱语的巨大挑战，解析的好处是它为您提供了分组和排序的维度。例如邮政编码。但是，在您需要对该维度进行分组或排序之前，解析特定维度是没有回报的。
究竟什么是地址？你可以很好地说明它是一个位置标识符，但你也可以很好地说明它是交货说明——“在水泥厂的街上”。在澳大利亚，人们认为邮政编码是位置标识符，但事实并非如此，它们是路线代码 - 递送说明。4702 是罗克汉普顿邮件中心，这是一个主要的配送节点，服务于从海洋延伸到内陆 300 公里的采矿小镇 Emerald 的地区。
如果您想识别位置，那么 Bing 和 Google 可以直接从未解析的字符串地理编码为 GPS 坐标，该坐标可以与未解析的字符串一起存储在一个小的、简单的表中。他们使用唯一有机会获得始终良好结果的通用方法：排名加权部分匹配与验证结果的庞大数据库。
如果您需要交付说明，仍然建议您保留未解析的字符串，因为它可能包含任何内容。
请注意，在这两种情况下，我都建议保留未解析的字符串。那是因为
可以说，地址始终是交付说明，至少包含一个位置标识符。一封写给“123 Main st, Emerald 4702”的信包含三个位置：Rockhampton 北部的 RMC、Emerald 和一个街道地址。Rockhampton 邮局只会将其发送给 RMC。RMC 会将其发送到 Emerald 邮局，Emerald 邮局希望知道在哪里可以找到 123 Main Street。
| 归档时间： |
|
| 查看次数： |
5715 次 |
| 最近记录： |