132

我是一名程序员，需要一种实用的方法来将世界的街道地址结构存储在数据库中。那么存储街道地址的最佳和通用数据库设计是什么？它应该易于使用、快速查询和动态存储世界上所有的街道地址。

4

12 回答 12

136

可以在一组标准字段中表示来自许多不同国家的地址。命名或编号建筑物所在的命名通道（通道）的基本概念是相当标准的，有时在中国除外。其他近乎普遍的概念包括： 命名定居点（城市/城镇/村庄），通常可以称为地方；命名该地区并分配一个字母数字邮政编码。请注意，邮政编码（也称为邮政编码）仅在某些国家/地区是纯数字的。如果您真的想要通用，您将需要很多字段。

万国邮政联盟 (UPU) 以标准格式为许多国家/地区提供地址数据。请注意，万国邮联格式包含整个国家的所有地址（直至可用字段精度），因此它是相关的。如果存储客户地址，其中仅存储所有可能地址的一小部分，最好使用包含所有字段和每行一个地址的单个表（或平面格式）。

存储地址的合理格式如下：

  • 地址行 1-4
  • 地方性
  • 地区
  • 邮政编码（或邮政编码）
  • 国家

地址行 1-4 可以包含以下组件：

  • 建造
  • 子楼
  • 房屋号码（门牌号）
  • 前提范围
  • 通道
  • 次通道
  • 双重依赖的地方
  • 次区域

通常只使用 3 条地址线，但这通常是不够的。当然可以要求更多行来表示官方格式的所有地址，但逗号始终可以用作行分隔符，这意味着仍然可以捕获信息。

通常数据的分析会按地点、地区、邮政编码和国家进行，这些元素在用户输入数据时很容易理解。这就是为什么这些元素应该存储为单独的字段。但是，不要强迫用户提供邮政编码或地区，它们可能不会在本地使用。

地点可能不清楚，尤其是地图地点和邮政地点之间的区别。邮政地区是邮政当局认定的地区，有时可能是附近的大城镇。但是，邮政编码通常会解决那里的任何问题或差异，即使没有使用官方邮政地址，也可以正确交付。

于 2009-05-30T22:57:21.733 回答
49

看看数据库答案。具体来说，这涵盖了许多情况：

（所有可变长度字符数据类型）

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

在此处输入图像描述

于 2009-05-30T12:50:22.833 回答
27

问问自己存储这些数据的主要目的是什么？您是否打算实际向该地址的人发送邮件？跟踪人口统计、人口？作为一些基本身份验证/验证的一部分，能否向呼叫者询问他们的正确地址？上述所有的？以上都不是？

根据您的实际需要，您将确定 a) 它并不重要，您可以采用自由文本方法，或 b) 所有国家/地区的结构化/特定字段，或 c) 国家/地区特定架构。

于 2009-05-30T19:51:35.383 回答
12

有时，您可以到达的最接近街道地址的是城市。

我曾经有一个项目将印度所有的中学都放在谷歌地图上。我使用 Google API 编写了一个漂亮的程序，并认为它会很容易。

然后我从客户那里得到数据。一些学校地址是“市场对面，理发店旁边”或“旧巴士站附近”之类的东西。

这让我的任务变得更加困难，因为不幸的是，Google API 不支持这种格式。

于 2009-06-02T11:04:35.330 回答
10

对于国际地址，如果将信息分解为字段，则很难找到一种方法来格式化信息。例如，意大利地址使用：

<street address>
<zip> <town> <region>
<country>

如

Via Eroi della Repubblica
89861 Tropea VV
Italy

这与美国地址的顺序大不相同 - 在第二行。

另请参阅 SO 问题：

另请查看标签“邮政编码”。

编辑：地区和城镇的倒序 - 每个万国邮联

于 2009-05-30T22:43:17.330 回答
5

也许这很有用： https ://gist.github.com/259744 对于一个项目，我收集了一张关于世界所有国家/地区的信息表，包括 ISO 代码、顶级域、电话代码、汽车标志、长度和正则表达式压缩。不幸的是，国名和评论只有德语......

于 2010-12-15T20:40:43.163 回答
3

与这里的其他答案不同，我相信可以拥有一个结构化的地址数据库。

刚出帽子，我可以想到以下结构：

  • 国家
  • 地区（州/省）
  • 地区（市/市）
  • 次地区（县/地区的其他细分）
  • 街道

但是如何足够快地查询呢？

我一直认为可以实现的一种方法是询问邮政编码（或邮政编码），它因国家而异，但在国内是可靠的。

通过这种方式，您可以围绕世界各地邮局提供的信息构建数据。

于 2009-05-30T13:01:39.940 回答
2

不，绝对不是。如果您比较美国和日本地址的工作方式，您会发现这是不可能的。

更新：

再想一想，任何事情都可以做，但有一个权衡。

一种方法是使用 address 和 address_attribute 表对问题进行建模，它们之间具有 1:m 的关系，任何东西都可以建模。address_attribute 表将包含一个 pk、一个名称、一个值和一个指向其地址父级 pk 的 fk。这几乎就像使用带有名称、值对的 Map 一样。

每次您想要一个地址时，都必须进行一次 JOIN 操作。您还必须询问 address_attributes 的名称以弄清楚您每次处理的内容。

另一种方法是对全球地址的建模方式进行更全面的研究。在面向对象的世界中，您可能拥有西方地址类 (street1/street2/city/state/zip) 以及日本、中国的其他地址类，根据需要平铺地址空间。然后，您将拥有一个主地址表和其他类型的子表，它们之间具有 1:1 的关系。

亚马逊或易趣如何做到这一点？他们在国际上运送。他们是否具有特定于语言环境的 UI 功能？我只使用了美国语言环境。

于 2009-05-30T12:50:39.543 回答
2

取决于您准备使用这些字段的自由形式。一个自由格式的地址字段显然总是可以的，但对缩小地理范围的帮助相对较小。

您将遇到的问题是，不同国家/地区的地理等级差异太大。哎呀，有些国家甚至没有到处都有“街道地址”。

我建议你不要试图让它太聪明。

于 2009-05-30T12:51:40.990 回答
2

Universal Data Model的 Len Silverston推荐了一个单独的层次结构，GEOGRAPHIC BOUNDARIES这取决于您愿意接受简单STREET ADDRESS LINE的 s 或每个国家/地区的衍生品的自由度。

于 2009-05-30T13:02:13.513 回答
2

不，没有标准的寻址方案。它通常因国家而异。就连万国邮政联盟在“ Adressing the world, a address for everyone ”一文中也说没有。对此的最佳解决方案是使用称为ISO 3166的 2/3 个字母的国家代码标准，并按国家标准处理其他所有内容。

但是，如果您真的很想为您的项目使用易于访问的工具，您可以尝试Google Place API。

于 2013-08-23T13:44:06.297 回答
1

你的设计应该很大程度上取决于你的目的。有些人发布了如何构造数据。因此，如果您只是想向某人发送 s-mail，它就可以了。如果您想使用这些数据进行导航，事情就会变得复杂。汽车导航将需要额外的结构来包含交通信息（例如单向道路），而步行导航将需要大量额外的数据。这是一个小例子：在我的城市，我的社区靠近公园。公园旁边是前机场（实际上是欧洲最古老的机场之一）变成了航空博物馆。航空博物馆旁边是一个商业园区。博物馆的门牌号是 39，而商业园的门牌号是 39A。所以看起来 39 和 39A 似乎很近——但从一个到另一个步行大约需要一英里（如果开车去，甚至更长）。
这只是我所在城市的一个小例子，我认为您可能会发现很多例外情况（尤其是在每个国家的农村或荒野地区）。

于 2009-06-02T10:30:21.873 回答