Question

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

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

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

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)

我学到的课程：

不要以数字方式存储任何内容。
尽可能将国家/地区和行政区域存储为ISO代码。
当你不知道时，对要求字段要宽容。某些国家/地区可能不会使用您认为理所当然的字段，甚至是基本的内容，例如locality＆amp; thoroughfare。

Answer 2

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

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

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

Answer 3

你绝对应该考虑将门牌号码存储为字符字段而不是数字，因为特殊情况如“半数字”或我当前的地址，类似于“129A” - 但不考虑A作为送货服务的公寓号码。

Answer 4

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

Frank's Compulsive Guide to Postal Addresses
有效解决国际邮件

Answer 5

我已经这样做了（严格模拟数据库中的地址结构），我再也不会这样做了。您无法想象作为一项规则您必须考虑的异常是多么疯狂。

我含糊地回忆起挪威邮政编码的一些问题（我认为），除奥斯陆外，还有4个职位，其中有18个左右。

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

（我们最终在国内注册了具有ISO代码'ZZ'的国外地址的人。）

Answer 6

你当然应该咨询“Is this a good way to model address information in a relational database”，但你的问题不是直接重复。

肯定存在许多预先存在的答案（例如，查看DatabaseAnswers处的示例数据模型）。在某些情况下，许多预先存在的答案都是有缺陷的（根本没有选择DB Answers）。

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

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

Answer 7

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

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

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

Answer 8

添加@ Jonathan Leffler和@ Paul Fisher所说的内容

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

Answer 9

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

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

Answer 10

将ZIP存储为NUMBER或VARCHAR的“权衡”在哪里？这只是一个选择 - 除非两者都有好处，否则你不得不放弃权衡，而你必须放弃一些好处才能获得其他人。

除非拉链的总和有任何意义，否则Zips作为数字是没有用的。

Answer 11

这可能是一种矫枉过正，但是如果您需要一个适用于多个国家/地区的解决方案，并且您需要以编程方式处理地址的某些部分：

您可以使用两个表来处理特定于国家/地区的地址：一个通用表，其中包含10个VARCHAR2列，10个数字列，另一个表将这些字段映射到提示，并且具有将地址结构绑定到国家/地区的国家/地区列。

Answer 12

如果您必须验证地址或使用它来处理信用卡付款，您至少需要一点结构。一个自由格式的文本块对此不起作用。

邮政编码是一个常见的可选字段，用于在不使用整个地址的情况下验证支付卡交易。所以有一个单独的，宽大的领域（至少10个字符）。

Answer 13

受Database Answers启发

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Answer 14

我只是将所有字段放在一个大的NVARCHAR（1000）字段中，并使用textarea元素为用户输入值（除非你想对例如邮政编码进行分析）。所有那些地址第1行，地址第2行等输入都是如此令人讨厌，如果你的地址不符合这种格式（并且，你知道，还有其他国家而不是美国）。

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

14 个答案: