4

几乎每次构建应用程序时,我都会发现自己创建了一个“地址”表来包含系统的地址。

你在你的“地址”表中创建了哪些列(或者如果你对多个地址进行规范化的表),你的理由是什么?

4

3 回答 3

4
  • 1号线
  • 2号线
  • 3号线
  • 地方性
  • 地区
  • 邮政编码
  • 国家(作为国家表的外键)

不包括国家,所有这些字段都是文本(varchar)。

这假定收件人存储在其他地方。

例如,丢失其中一行并将其替换为:

  • 街道号码
  • 街道名称

因为这有助于验证、通过 Web 服务查找地址等。

于 2009-09-11T02:14:38.123 回答
2

我要折腾一个“这取决于”的答案。如果您的应用程序只关心正确打印的地址标签的布局,那么一组行(line1、line2、line3 等)就足够了。文本 blob 也可以工作,具体取决于数据的输入方式。给用户一个盒子让他们输入?让它们适合 3、4、5 行?任何。

但是,如果您希望能够对数据进行“处理”,例如按邮政编码排序,按城市、州和/或国家/地区分析分布,或者跟踪您的街道地址(10 Main St. vs. 54321 Main St.),那么您需要为每条重要信息设置单独的列。

似乎要求将是“包括地址空间”,并且关于实际处理地址的决定将在稍后提出......届时他们将希望能够排序/计数/取幂/无论如何,即使他们永远不会真正做到这一点。根据其他帖子中引用的链接,一旦你走向国际,它确实会变得非常复杂。我想说尽量保持简单合理,其中“合理”取决于需求背后的业务推理。

于 2009-09-11T03:34:25.217 回答
1

在理想情况下,每个应用程序都会以规范格式(例如 UPU 或 BS7666)存储地址。将结构化地址合并为单个字符串以进行打印比随后从单个文本块中提取地址元素要容易得多。因为迟早会有人,也许不是你,会想要用地址信息“做点什么”。如今,数据仓库非常流行。

不幸的是,实现类似BS7666的东西通常需要地址验证软件。要求普通用户将地址适合 procrustean 格式是不合理的:我们不能指望他们会理解 a locality、 atown和 a之间的区别post town。并且在未经验证的情况下将某些东西吹捧为标准格式是一种误导。

但是选择某种形式的结构。此外,至少使用正则表达式验证邮政编码/zip 以确保其格式正确。

于 2009-09-11T05:18:36.597 回答