在数据库中存储国际地址的“最佳”方式是什么？

Question

是什么 ”最好的“在数据库中存储国际地址的方法？以模式的形式回答，并解释您选择标准化（或不标准化）方式的原因。还要解释为什么选择每个字段的类型和长度。

笔记：您可以决定您认为必要的字段。

Answer 1

纯自由格式文本。

验证世界上所有的邮政编码太难了；固定的国家名单在政治上过于敏感；强制性的州/地区/其他行政分区显然是不合适的（我经常被问到我住在哪个县——而我没有这样做，因为大伦敦根本不是一个县）。

更重要的是，这是完全没有必要的。您的应用程序不太可能以任何严肃的方式对地址进行建模。如果您需要邮政地址，请询问邮政地址。大多数人不会愚蠢到输入邮政地址以外的其他内容，如果他们这样做了，他们就可以和新购买的物品吻别了。

例外情况是，如果您正在做的事情自然仅限于一个国家/地区。在这种情况下，您应该询问 { 邮政编码, 门牌号 } 对，这足以识别邮政地址。我想您可以通过美国的扩展邮政编码实现类似的目标。

Answer 2

过去，我在他们网站上的 ups/fedex 送货地址表格之后对需要国际化的表格进行了建模（我想如果他们不知道如何处理国际订单，我们都会被淘汰）。他们使用的字段可以用作设置架构的参考。

Answer 3

一般来说，您需要了解为什么需要地址。是用于运输/邮寄吗？那么实际上只有一个要求，就是将国家分开。其他行是自由格式，由用户填写。原因是邮件常见的转发策略：任何发往国外的传入邮件都会被转发，而无需查看其他地址行。因此，详细信息仅由位于该国本身的邮件分拣机解析。与接收者一样，他们也会熟悉国家会议。

（UPS 可能会聚集一些欧洲小国家，例如......所有低地国家可能都由比利时提供服务 - 这个想法仍然成立。）

Answer 4

我认为添加国家/城市和地址文本就可以了。国家和城市应分开报告。经理人 总是 要求提供您不期望的此类报告，并且我不喜欢通过大型数据库运行 LIKE 查询。

Answer 5

不要给予 Facebook 不适当的尊重。然而，在每天启动的许多 Web 应用程序中，数据库的整体结构似乎被忽视了。显然，我不认为有一个完美的解决方案可以在不进行一些艰苦工作的情况下覆盖所有具有地址结构的潜在变量。也就是说，结合自动完成功能，Facebook 设法获取位置输入数据并消除大部分冗余条目。他们通过很好地组织数据库来以低成本、低错误的方式向客户实时提供自动完成信息，从而使他们或多或少地从现有列表中选择正确的位置来做到这一点。

我认为最好的解决方案是访问包含您所需的地理范围的第三方数据库，并使用它来最初播种您的用户位置信息。这将使您避免进行创建自己的基础工作。如果幸运的话，您可以通过允许新用户直接从第三方供应商接收正确的自动完成信息来减少服务器上的负载。最终，您将能够填写大多数自动完成位置信息，例如城市、国家/地区等。来自您自己的数据库中包含的信息以及用户输入数据。

Answer 6

您需要提供有关计划如何使用数据的更多详细信息。例如，城市、州、国家/地区等字段可以是单个表中的文本，也可以是使用外键链接到单独表的代码。

最简单的是

advelly_line_01（必需，非空白）地址_line_02地址_LINE_03地标城市（必需）PIN（必需）

以上所有内容都可以是具有适当字段长度的文本/Unicode。

适用的电话号码。