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

Question

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

注意：您决定您认为哪些字段是必要的。

Answer 1

纯自由格式文本。

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

更重要的是，这根本没有必要。您的应用程序极不可能以任何严肃的方式对地址进行建模。如果您想要邮政地址，请询问邮政地址。大多数人不会傻到输入邮政地址以外的其他东西，如果他们这样做了，他们可以亲吻他们新购买的物品再见。

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

Answer 2

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

Answer 3

一般来说，您需要了解为什么需要地址。是用于运输/邮寄吗？然后真的只有一个要求，把国家分开。其他行是自由格式，由用户填写。这样做的原因是邮件的常见转发策略：任何来自外国的传入邮件都会被转发而无需查看其他地址行。因此，详细信息仅由位于该国家/地区的邮件分拣机解析。像接收者一样，他们会熟悉全国大会。

（UPS 可能会将一些欧洲小国聚集在一起，例如……所有低地国家可能都来自比利时——这个想法仍然成立。）

Answer 4

我认为添加国家/城市和地址文本会很好。国家和城市应该分开报告。经理们总是要求你提供这些你意想不到的报告，我不喜欢通过大型数据库运行 LIKE 查询。

Answer 5

不要给 Facebook 过分的尊重。但是，在每天启动的许多 Web 应用程序中，似乎都忽略了数据库的整体结构。显然，我认为没有一个完美的解决方案可以覆盖所有具有地址结构的潜在变量，而无需付出一些努力。也就是说，与自动完成相结合，Facebook 设法获取位置输入数据并消除大部分冗余条目。他们通过将数据库组织得足够好，以低成本、低错误的方式实时向客户提供自动完成信息，从而使他们或多或少地从现有列表中选择正确的位置来做到这一点。

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

Answer 6

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

最简单的是

Address_Line_01（必填，非空白） Address_Line_02 Address_Line_03 地标城市（必填） Pin（必填） Province_District 州（必填） 国家（必填）

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

电话号码（如适用）。