小编Gre*_*rdt的帖子

将街道地址拆分为单独的列解决了哪些问题?

我们有一个团队为软件开发人员设计表格和关系。在我们的组织中,他们对执行 3NF 规范化非常严格——老实说,鉴于我们组织的规模以及需求或我们的客户如何随时间变化,我同意这一点。只有一个方面我不清楚他们设计决策背后的原因:地址。

虽然这主要集中在美国的地址,但我认为这适用于任何这样做的国家。地址的每一部分在地址表中都有自己的列。例如,以这个粗糙的美国地址为例:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222
Run Code Online (Sandbox Code Playgroud)

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

  • 街道号码:485
  • 街道分数:1/2
  • 街道预定向:N(北)
  • 街道名称:史密斯
  • 街道类型:ST(街道)
  • 街道后向:西南(西南)
  • 城市:芝加哥
  • 州:IL(伊利诺伊州)
  • 邮编:11111
  • 邮政编码:2222
  • 国家(假设为美国)
  • 注意:简·多伊
  • 邮政信箱: NULL
  • 户型:APT(公寓)
  • 户数:300B

还会有一些其他与农村路线和合同路线相关的专栏。此外,我们的特定应用程序中可能会包含一些国际地址。数据建模人员表示,他们将添加特定于国际地址的列,这将是正常的第 1 行、第 2 行字段。

起初我认为这太过分了。在网上反复搜索是指使用地址行 1、2、3 和可能的 4,然后拆分出城市、地区和邮政编码。我们的新应用程序确实有一个用例,这种粒度是有益的。我们必须验证用户没有创建重复的业务,检查地址是验证之一。我们可以让它与地址行 1 和 2 一起工作,但这会更困难。

至于我们的具体应用,我们需要为企业和个人存储多种地址(物理、邮寄、运输等)。我们可能需要生成可打印的套用信函,但目前尚未讨论该要求。

我们组织中的应用程序需要支持的其他一些东西:

  • 审计(使用完整的历史表)
  • 打印邮寄标签
  • 生成打印表格
  • 报告(针对国家和地区政府)

虽然我们的应用程序可能不会做所有其他应用程序正在做的所有事情,但将地址拆分为多个组件是我工作的企业标准。不管我们的应用程序是否会从中受益,我们都被迫这样做。

半相关的 StackOverflow 问题:关闭的好的地址解析器在哪里,但说明解析地址有多么困难。

为了让我更好地理解他们的设计决策,并把这个想法卖给我们的客户……

将街道地址拆分为单独的列解决了哪些问题?

任何实施过此类系统的人都会获得奖励积分,因为他们遇到了问题。

normalization database-design best-practices address

26
推荐指数
4
解决办法
5715
查看次数