将邮政地址存储在数据库(RDBMS)中的最佳做法？

在RDBMS中存储邮政地址的最佳实践是否有任何好的参考？似乎有很多可以做出的权衡,并且每个都有很多优点和缺点需要评估 - 当然这已经一次又一次地完成了吗？也许有人至少写过一些在某处学到的经验教训？

我所讨论的权衡的例子是将邮政编码存储为整数与char字段,如果房屋号码存储为单独的字段或地址行1的一部分,如果套房/公寓/等号码被标准化或仅存储为地址行2中的文本块,如何处理zip +4(单独的字段或一个大字段,整数与文本)？等等

我现在主要关注的是美国地址,但我想有一些最好的做法可以帮助你做好全球化的可能性(例如,将地域命名为区域而不是州或邮政编码,而不是邮政编码,等等

1> 小智..：

---

为了更多的国际使用,需要考虑的一个模式是Drupal Address Field使用的模式.它基于xNAL标准,似乎涵盖了大多数国际案例.对该模块的一些挖掘将揭示一些用于解释和验证国际地址的珍珠.它还有一套很好的行政区域(省,州,州等)和ISO代码.

这是从模块页面复制的模式的要点:

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

我学到的课程:

不要以数字方式存储任何东西.

尽可能将国家和行政区域存储为ISO代码.

当你不知道时,对要求字段要宽容.有些国家可能不会使用您认为理所当然的字段,甚至是像locality&这样的基本内容thoroughfare.

2> Andrew Ferri..：

---

作为一个"国际"用户,没有什么比处理仅以美国格式地址为导向的网站更令人沮丧的了.起初有点粗鲁,但当验证过于热心时,它就成了一个严重的问题.

如果你担心走向全球化,我唯一的建议是保持自由形式.不同的国家有不同的惯例 - 在某些情况下,门牌号码出现在街道名称之前,有些则出现在街道名称之前.有些州有州,有些地区,有些县,有些县的组合.在英国,邮政编码不是邮政编码,它是包含字母和数字的邮政编码.

我只建议~10行可变长度的字符串,以及一个单独的字段用于邮政编码(并且要小心你如何描述它以应对国家的敏感性).让用户/客户决定如何写他们的地址.

---

虽然我不同意这个消息,事实上我为你采取的立场鼓掌,但我不得不向你投票,因为我厌恶这样一个事实,就是那些花费我大部分时间编写工具来清理地址数据的人以自由格式存储地址数据.地址的格式可能不同,但数据仍然大致相同.是否在街道名称之前或之后显示街道号码与存储目的无关 - 仅用于显示目的.

3> splattne..：

---

如果您需要有关其他国家如何使用邮政地址的全面信息,这里有一个非常好的参考链接(哥伦比亚大学):

弗兰克的邮政强制性指南
有效解决国际邮件问题

4> Paul Fisher..：

---

您应该考虑将门牌号码存储为字符字段而不是数字,因为特殊情况如"半数"或我当前的地址,如"129A" - 但A不被视为公寓送货服务号码.

5> 小智..：

---

我已经完成了这个(严格模拟数据库中的地址结构),我再也不会这样做了.您无法想象作为规则您必须考虑的异常是多么疯狂.

我含糊地回忆起挪威邮政编码的一些问题(我认为),这些问题都是4个职位,除了奥斯陆,其中有18个左右.

我确信从我们开始使用地理位置正确的邮政编码到我们所有国家地址的那一刻起,很多人开始抱怨他们的邮件来得太晚了.事实证明,那些人住在邮政区域之间的边界附近,尽管事实上有人真的住在邮政区域,比如1600,实际上他的邮件应该发往邮政区域1610,因为实际上这是邻近的邮政区域这实际上是为他提供服务,因此将邮件发送到他正确的邮政区域会使邮件再过几天才会到达,因为正确的邮局需要进行不必要的干预才能将邮件转发到错误的邮政区域......

(我们最终在国内注册了具有ISO代码'ZZ'的国外地址的人.)

6> Jonathan Lef..：

---

您当然应该参考" 这是一种在关系数据库中建模地址信息的好方法 ",但您的问题并不是直接重复.

肯定有很多预先存在的答案(例如,查看DatabaseAnswers上的示例数据模型).许多预先存在的答案在某些情况下是有缺陷的(根本没有选择DB Answers).

要考虑的一个主要问题是地址的范围.如果您的数据库必须处理国际地址,那么您必须比只需处理一个国家/地区的地址更灵活.

在我看来,记录地址的"地址标签图像"并分别分析内容通常(并不总是意味着)是明智的.这使您可以处理邮政编码的位置之间的差异,例如,不同国家/地区之间的差异.当然,你可以编写一个分析器和一个格式化程序来处理不同国家的怪癖(例如,美国地址有2或3行;相比之下,英国地址可以有更多;我写的一个地址定期有9行).但让人类进行分析和格式化并让DBMS只存储数据会更容易.

7> seanb..：

---

除非你要对街道号码或邮政编码进行数学计算,否则你只是将它们存储为数字,从而引发未来的痛苦.

你可以在这里和那里保存几个字节,也许可以获得更快的索引,但是当你在美国邮政或你正在处理的其他任何国家时,你决定将代码引入代码？

磁盘空间的成本将比以后修复它的成本便宜很多... y2k任何人？

8> Gaz_Edge..：

---

我发现列出从最小的离散单位到最大的所有可能的字段是最简单的方法.用户将填写他们认为合适的字段.我的地址表如下所示:

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

9> Ken Gentle..：

---

加上@ Jonathan Leffler和@Paul Fisher所说的话

如果您预计加拿大或墨西哥的邮政地址符合您的要求,postal-code则必须存储为字符串.加拿大有字母数字邮政编码,我不记得墨西哥的外观是什么样的.