世界上所有的地址都有通用的街道地址数据库设计吗？

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

97342 次浏览
小开

看一下 数据库答案。具体来说，它涵盖了许多情况:

(所有可变长度字符数据类型)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

enter image description here

小开

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

更新:

转念一想，什么事都可以做，但是有一个交易。

一种方法是使用 address 和 address _ tribute 表对问题进行建模，它们之间的关系为1: m，可以对任何内容进行建模。Address _ tribute 表包含一个 pk、一个名称、一个值和一个指向其地址父节点 pk 的 fk。这几乎就像使用带有名称和值对的 Map。

权衡之下，每次您想要一个地址时，都必须执行一个 JOIN。您还必须询问 address _ Attribute 的名称，以确定每次处理的内容。

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

亚马逊和易趣是怎么做到的？他们在国际上运输。它们具有特定于语言环境的 UI 特性吗？我只用了美国的地方。

小开

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

你会遇到的问题是，不同国家之间的地理等级层次差异太大。见鬼，有些国家甚至到处都没有“街道地址”。

我建议你不要把它想得太聪明。

小开

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

脱口而出，我能想到以下结构:

  • 国家
  • 地区(州/省)
  • 地点(市/市)
  • 分区(县/地区的其他分区)
  • 街道

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

我一直认为可以完成的一个方法是要求邮政编码(或邮政编码) ，它因国家而异，但在国内是可靠的。

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

小开

著名的 通用数据模型的 Len Silverston 推荐了一个独立的 GEOGRAPHIC BOUNDARIES层次结构，这取决于你愿意接受多少自由形式的 STREET ADDRESS LINE或者每个国家的衍生产品。

小开

问问你自己存储这些数据的主要 目的是什么？你真的打算给这个地址的人发邮件吗？跟踪人口统计，人口？作为一些基本的认证/验证的一部分，是否可以要求来电者提供正确的地址？以上都是？都不是吗？

根据您的实际需要，您可以确定: a)这并不重要，您可以采用自由文本方法，或者 b)针对所有国家的结构化/特定字段，或者 c)针对具体国家的架构。

小开

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

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

比如

Via Eroi della Repubblica
89861 Tropea VV
Italy

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

另请参阅“所以”问题:

也可以查看标签“ 邮政编码”。

编辑 : 地区和城镇的相反顺序-每个邮政编码 = “ http://www.UPU.int/post _ code/en/post _ address _ systems _ member _ country. shtml”rel = “ nofollow noReferrer”> UPU

小开
最佳答案

可以在一组标准字段中表示来自许多不同国家的地址。命名通道(大道)的基本思想是相当标准的命名或编号的建筑物所在的位置，除了在中国有时。其他接近普遍的概念包括: 命名定居点(城市/镇/村庄) ，这可以通常称为一个地方; 命名区域和分配一个字母数字的邮政编码。请注意，邮政编码，也称为邮政编码，纯粹是数字只在一些国家。如果您真的想要成为通用的，那么需要很多字段。

该万国邮政联盟(万国邮政总局)在一个 标准格式中为许多国家提供地址数据。注意，UPU 格式包含整个国家的所有地址(精确到可用的字段精度) ，因此它是关系型的。如果存储客户地址(只存储所有可能地址的一小部分) ，最好使用包含所有字段和每行一个地址的单个表(或平面格式)。

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

  • 地址第1-4行
  • 地点
  • 区域
  • 邮政编码(或邮政编码)
  • 国家

地址行1-4可以保存下列组件:

  • 大楼
  • 副楼
  • 楼宇编号(门牌号码)
  • 范围
  • 大道
  • 地下通道
  • 双相依局部性
  • 次区域

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

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

地域性可能不清楚，特别是地图地域性和邮政地域性之间的区别。邮政所在地是邮政当局认为的地方，有时可能是附近的大城镇。然而，邮政编码通常会解决任何问题或差异有，以允许正确的交付，即使官方邮政地点没有使用。

小开

你的设计应该与你的目的密切相关。一些人已经发布了如何构造数据。因此，如果你只是想发送电子邮件给某人，它会做。如果您想使用这些数据进行导航，事情就开始变得复杂了。汽车导航将需要额外的结构，以包含交通信息(如单向道路) ，而徒步导航将需要大量的额外数据。这里有一个小例子: 在我所在的城市，我的邻居就在公园附近。公园旁边是以前的机场(事实上是欧洲最古老的机场之一) ，后来改建成了航空博物馆。航空博物馆旁边是一个商业园区。博物馆的街道号码是39，而商业公园的街道号码是39A。所以39和39A 看起来很接近——但是从一个地方走到另一个地方大约需要一英里(如果开车的话甚至更长)。
这只是我所在城市的一个小例子，我想你可能会发现很多例外(特别是在每个国家的农村或荒野地区)。

小开

有时候离街道地址最近的地方是城市。

我曾经有一个项目，把所有的印度中学在谷歌地图。我使用 GoogleAPI 编写了一个漂亮的程序，并认为它会非常容易。

然后我从客户那里拿到了数据。有些学校的地址是“市场对面，理发店旁边”或“靠近旧公交站”。

不幸的是，Google API 不支持这种格式，这让我的任务更加艰巨。

小开

也许这是有用的: Https://gist.github.com/259744 对于一个项目，我收集了世界上所有国家的信息表，包括 ISO 代码，顶级域名，电话号码，汽车标志，邮政编码的长度和正则表达式。 不幸的是，只有德文的国名和评论..。

小开

没有，没有标准的地址方案。它通常因国而异。 甚至 万国邮政联盟在 向全世界发表讲话，每个人的讲话上也说没有。最好的解决方案是使用2/3个字母的国家代码标准 ISO 3166，并按照国家标准处理其他所有事情。

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


提交答案