虽然这主要集中在美国的地址,但我认为这适用于任何这样做的国家.每个地址都在地址表中有自己的列.例如,请把这个粗略的美国地址：
Attn: Jane Doe 485 1/2 N Smith St SW,APT 300B Chicago,IL 11111-2222
它将在数据库中拆分,如下所示：
>街道号码：485
>街道分数：1/2
>街道预定位：N(北)
>街名：史密斯
>街道类型：ST(街道)
>街道后方向：SW(西南)
>城市：芝加哥
>州：IL(伊利诺伊州)
>邮编：11111
> Zip4代码：2222
>国家(假设为美国)
>注意：Jane Doe
> P.O. Box：NULL
>住宅类型：APT(公寓)
>住宅数量：300B
还有一些与农村路线和合同路线相关的其他栏目.此外,我们的具体应用可能会有一些国际地址.数据建模者表示,他们将添加特定于国际地址的列,这将是正常的第1行,第2行字段.
起初我以为这是过分了.在线反复研究是指使用地址线1,2,3和可能4,然后拆分城市,地区和邮政编码.我们的新应用程序有一个用例,其中这种粒度是有益的.我们必须验证用户没有创建重复的业务,并且检查地址是验证之一.我们可以使用地址第1行和第2行,但这将更加困难.
至于我们的具体应用,我们需要为企业和人员(物理,邮寄,运输等)存储多种地址.我们可能需要生成可打印的套用信函,但到目前为止还没有讨论过该要求.
我们组织中的其他一些应用程序需要支持：
>审核(包含完整的历史记录表)
>打印邮件标签
>生成印刷表格
>报告(针对国家和地区政府)
虽然我们的应用程序可能没有执行其他所有应用程序正在执行的所有操作,但将地址拆分为多个组件是我工作的企业标准.无论我们的应用程序是否会从中受益,我们都被迫这样做.
半相关的StackOverflow问题：Where is a good Address Parser已关闭,但说明了解析地址的难度.
为了让我更好地了解他们的设计决策,并向我们的客户推销这个想法……
将街道地址拆分为单独的列可以解决哪些问题？
任何已实施此类系统的人都会获得奖励积分,因为他们遇到了问题.
解决方法
验证可以将名称的任何一部分与主列表进行比较.那些不匹配的可以被拒绝.邮政编码/邮政编码是一个明显的例子.这些由独立机构发布和维护.唯一有效的是那个机构发布的那些.
排序和选择我已经看到如果邮件被递送到已经在某种程度上组织的递送服务,邮政费用减少的情况.拥有相应的列可以产生切实的商业价值.
分析以地理分层方式了解订单的去向非常有用.这可能会推动销售计划,产品开发或佣金支付等.
代码复制通过使组织中的所有应用程序采用相同的数据模型(最复杂的消费者),可以在整个企业范围内采用单一代码库并保持一致.可以避免无限重复的头发分裂,或者至少委托给螺旋桨头.组织的不同部分持有的地址可以一致地更新.可以增加客户服务和满意度.开发工作可以集中在系统的独特,高价值部分.
法律问题法律和税收因司法管辖区而异.通过单独捕获详细地址值,可以更容易地将事务数据交叉引用到合规性要求.
复制通过将一个元素移动到下一行或重新排序某些部分来欺骗作为文本保存的地址很简单.完全解析的地址更容易比较.这可能是一个简单的数据质量问题,或者如果多个空壳公司向同一个交货地址发出大订单,或者信用卡用于在短时间内交付到许多分散的地点,则可能具有合规性或信用影响.
格式化单独保存的零件可以按照当前需要的任何方式组合.例如,如果长薄标签变得便宜,您可以重新格式化以使用它们.
当然,这些都不适用于任何特定的应用.这种类型的数据在收集时比在后期分析中更容易在源头进行解析和验证.因此,即使YAGNI,也可以更好地将额外的努力放在前面,只需要很少的成本和潜在的大量未来节省.
最后,我不会忽视人为因素.数据模型由数据建模者生成.这就是他们所做的.那是他们的职业.他们不会告诉你把它丢弃在BLOB中,是吗？
