在数据库(RDBMS)中存储邮政地址的最佳实践？

Question

对于在RDBMS中存储邮寄地址的最佳实践，有什么好的参考吗？似乎可以做出很多权衡，每个权衡都有很多利弊需要评估--当然这已经做了一次又一次了？也许有人至少在某处写下了一些经验教训？

我正在讨论的权衡的例子是将邮政编码存储为整数和字符字段，门牌号应该存储为单独的字段还是地址行1的一部分，套间/公寓等数字应该标准化还是只是存储为地址行2中的文本块，您如何处理zip +4 (单独的字段或一个大字段，整数和文本)？等。

在这一点上，我主要关心的是美国地址，但我想有一些最佳实践可以帮助您为走向全球的可能性做好准备(例如，适当地命名字段，如region而不是州或邮政编码，而不是邮政编码，等等)。

Answer 1

对于更广泛的国际使用，一种需要考虑的模式是Drupal Address Field使用的模式。它基于xNAL standard，似乎涵盖了大多数国际案例。深入研究一下这个模块，就会发现一些用于解释和验证国际地址的珍珠。它也有一组很好的行政区域(省，州，州，等等)与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)

我学到的一课：

在可能的情况下，不要将任何numerically.

• Store国家和行政区域存储为
• 。
• 当你不知道的时候，不要在要求字段方面松懈。有些国家可能不会使用你认为理所当然的字段，甚至不会使用像locality和thoroughfare.

这样的基本字段

Answer 2

作为一个“国际”用户，没有什么比处理一个只面向美国格式地址的网站更令人沮丧的了。这一开始有点粗鲁，但当验证也过于热心时，它就会成为一个严重的问题。

如果你想要走向世界，我唯一的建议就是保持自由形式。不同的国家有不同的惯例-在一些国家，门牌在街道名称之前，在另一些国家，门牌在街道名称之后。一些州，一些地区，一些县，一些组合。在英国，邮政编码不是邮政编码，而是包含字母和数字的邮政编码。

我建议只使用10行左右的可变长度字符串，再加上一个单独的字段来表示邮政编码(并且要注意如何描述它，以应对国家敏感性)。让用户/客户决定如何书写他们的地址。

Answer 3

如果你需要其他国家如何使用邮寄地址的全面信息，这里有一个很好的参考链接(哥伦比亚大学)：

国际邮件的有效寻址