121

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

我正在谈论的权衡示例是将邮政编码存储为整数与字符字段，应将门牌号存储为单独的字段或地址行 1 的一部分，应将套房/公寓/等编号标准化还是仅存储为地址第 2 行中的一大段文本，你如何处理 zip +4（单独的字段或一个大字段，整数与文本）？等等

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

4

14 回答 14

49

对于更国际化的使用，要考虑的一种模式是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。
于 2015-01-17T02:08:06.033 回答
23

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

如果你关心走向全球，我唯一的建议就是保持自由形式。不同的国家有不同的约定——在某些情况下，门牌号在​​街道名称之前，在某些情况下在之后。有些有州，一些地区，一些县，还有这些的一些组合。在英国，邮政编码不是邮政编码，而是包含字母和数字的邮政编码。

我建议只使用大约 10 行可变长度字符串，以及一个单独的邮政编码字段（并注意如何描述它以应对国家敏感性）。让用户/客户决定如何写他们的地址。

于 2008-11-22T01:28:19.517 回答
23

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

弗兰克的邮政地址强制性指南
国际邮件的有效寻址

于 2010-09-13T07:33:22.887 回答
17

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

于 2008-11-21T23:53:27.867 回答
12

我已经这样做了（在数据库中严格建模地址结构），我再也不会这样做了。您无法想象作为规则必须考虑的例外情况有多疯狂。

我隐约记得挪威邮政编码的一些问题（我认为），它们都是 4 个位置，除了奥斯陆，它有 18 个左右。

我敢肯定，从我们开始为我们自己的所有国家地址使用地理上正确的邮政编码的那一刻起，相当多的人开始抱怨他们的邮件来得太晚了。原来这些人住在邮政区之间的边界附近，尽管有人真的住在邮政区，比如 1600，但实际上他的邮件应该寄往 1610 邮政区，因为实际上是相邻的邮政区这实际上为他服务，因此将他的邮件发送到他正确的邮政区域将需要几天的时间才能到达，因为正确的邮政局需要不必要的干预才能将其转发到不正确的邮政区域......

（我们最终用 ISO 代码“ZZ”注册了这些人在国外的地址。）

于 2009-06-09T00:31:54.173 回答
8

您当然应该咨询“这是在关系数据库中对地址信息建模的好方法吗”，但您的问题不是直接重复。

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

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

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

于 2008-11-21T23:46:24.263 回答
8

除非您要对街道号码或邮政编码进行数学运算，否则您只会通过将它们存储为数字来招致未来的痛苦。

您可能会在这里和那里节省一些字节，并且可能会获得更快的索引，但是当美国邮政或您正在处理的任何其他国家/地区决定在代码中引入字母时，您会怎么做？

磁盘空间的成本将比稍后修复它的成本便宜很多...... y2k有人吗？

于 2008-11-22T00:07:07.873 回答
8

补充@Jonathan Leffler和@Paul Fisher所说的

如果您预计将加拿大或墨西哥的邮政地址添加到您的要求中，postal-code则必须将其存储为字符串。加拿大有字母数字邮政编码，我不记得墨西哥在我脑海中的样子。

于 2008-11-22T00:09:12.737 回答
7

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

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************
于 2013-02-19T09:41:38.397 回答
3

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

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

于 2008-11-21T23:54:24.933 回答
2

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

您可以使用两个表来处理特定国家/地区的地址：一个具有 10 个 VARCHAR2 列、10 个数字列的通用表，另一个表将这些字段映射到提示，并具有将地址结构与国家/地区联系起来的国家/地区列。

于 2009-06-22T10:40:44.280 回答
1

如果您必须验证地址或使用它来处理信用卡付款，您至少需要一些结构。自由格式的文本块不能很好地解决这个问题。

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

于 2013-08-23T21:51:47.900 回答
1

受数据库答案的启发

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails
于 2015-01-15T12:37:18.153 回答
-2

我只是将所有字段放在一个大的 NVARCHAR(1000) 字段中，并带有一个 textarea 元素供用户输入值（除非您想对例如邮政编码进行分析）。如果您的地址不适合该格式（并且，您知道，还有美国以外的其他国家/地区），那么所有这些地址行 1、地址行 2 等输入都会非常烦人。

于 2010-09-13T07:43:57.683 回答