是否有世界上所有地址的常用街道地址数据库devise？
我是一个程序员，说实话，不知道世界的街道地址结构，只是在我的国家是如何组织:)这是最好的和常见的数据库devise，以存储街道地址？ 它应该是如此简单的使用，快速查询和dynamic存储世界的所有街道地址，只是由一个ID标识
非常感谢
在一组标准的字段中可以代表很多不同国家的地址。 有名或无名的build筑物所在的名称通道（通道）的基本思想是相当标准的，有时候在中国除外。 其他近乎普遍的概念包括：命名解决scheme（城市/乡镇/村庄），可以统称为地方; 命名该地区并分配字母数字邮政编码。 请注意，邮政编码也称为邮政编码，仅在某些国家/地区才是纯数字邮政编码。 如果你真的想成为通用的，你将需要很多领域。
万国邮政联盟万国邮政联盟以标准格式为许多国家提供地址数据。 请注意，UPU格式保存了整个国家的所有地址（低于可用的字段精度），因此是相关的。 如果存储客户地址，只存储所有可能地址的一小部分，则最好使用包含所有字段和每行一个地址的单个表格（或平面格式）。
存储地址的合理格式如下：
- 地址线1-4
- 局部性
- 地区
- 邮政编码（或邮政编码）
- 国家
地址线1-4可以容纳如下部件：
- build造
- 亚大厦
- 前提号码（门牌号码）
- 前提范围
- 通道
- 亚大道
- 双重依赖的地方
- 子局部性
通常只使用3个地址线，但这通常是不够的。 当然，可能需要更多的行来表示官方格式的所有地址，但逗号总是可以用作行分隔符，这意味着信息仍然可以被捕获。
数据分析通常通过地区，地区，邮政编码和国家进行，这些元素在input数据时对用户来说是比较容易理解的。 这就是为什么这些元素应该存储为独立的字段。 但是，不要强制用户提供邮政编码或地区，他们可能不会在本地使用。
地方可能不清楚，特别是地图地区和邮政地区之间的区别。 邮政区域是由邮政当局认定的，有时可能是附近的一个大镇。 但是，邮政编码通常会解决所有问题或差异，即使没有使用正式的邮政局域网，也能正确发送邮件。
看看数据库的答案 。 具体而言，这涵盖了许多情况：
AddressId Line1 Line2 Line3 City ZipOrPostcode StateProvinceCounty CountryId OtherAddressDetails 
问问自己，存储这些数据的主要目的是什么？ 你打算真的发邮件给地址的人吗？ 跟踪人口统计，人口？ 能够要求来电者的正确地址作为一些基本的authentication/validation的一部分？ 以上所有？ 以上都不是？
根据您的实际需要，您可以确定：a）其实并不重要，您可以采用自由文本方式，或者b）针对所有国家的结构化/特定的字段，或者c）特定于国家/地区的架构。
对于国际地址，如果将信息分解为字段，则很难find格式化信息的方法。 例如，一个意大利地址使用：
<street address> <zip> <town> <region> <country>
如
Via Eroi della Repubblica 89861 Tropea VV Italy
这与美国地址的顺序是相当不同的 – 在第二行。
另请参阅SO问题：
- 英国数据库将使用多less个地址字段？
- 你把地址分成街道/城市/州/邮编吗？
- 你如何处理重复的街道后缀？
- 在数据库中存储邮政地址的最佳实践（RDBMS）？
也检查标签“ 邮政编码 ”。
编辑 ：地区和城镇的颠倒顺序 – 每个万国邮联
有时候，最接近街道地址的就是城市。
我曾经有一个项目把所有在印度的中学放在Google地图上。 我用Google API编写了一个漂亮的程序，觉得这很容易。
然后我从客户那里得到了数据。 一些学校的地址是“市场对面，理发师旁边”或“靠近旧巴士站”。
这让我的任务更加困难，因为不幸的是，Google API不支持这种格式。
也许这是有用的： https ： //gist.github.com/259744对于一个项目，我收集了世界各国的信息表，包括ISO代码，顶级域名，电话代码，车牌，长度和正则expression式压缩。 国家名称和意见不幸只在德国…
不同的其他答案在这里，我相信有可能有一个结构化的地址数据库。
只是出于帽子，我可以想到以下结构：
- 国家
- 地区（州/省）
- 地点（市/区）
- 分地区（县/其他地区的分区）
- 街
但如何查询它足够快？
我一直认为可以做到的一个方法是要求邮政编码（或邮政编码），因国家而异，但在国内是稳固的。
通过这种方式，您可以围绕世界各地邮政局提供的信息构build数据。
取决于你准备如何自由地去田野。 一个自由forms的地址字段显然总是会这样做，但对缩小地理位置的帮助却相对较小。
您将遇到的问题是，各个国家/地区的地理等级水平差异太大。 哎呀，有些国家甚至都没有“街道地址”。
我build议你不要试图让它太聪明。
通用数据模型的 Len Silverstonbuild议使用单独的GEOGRAPHIC BOUNDARIES层次结构，根据自由形态的多less，您愿意接受简单的STREET ADDRESS LINE或每个国家的衍生产品。
不，没有标准的寻址scheme。 它通常因国家而异。 即使是万国邮政联盟在“世界地球”上也说过，对每个人来说 ，没有一个地址 。 最好的解决scheme是使用2/3字母的国家代码标准（ ISO 3166），并按照国家标准处理所有其他事项。
但是，如果您真的急于为您的项目使用易于访问的工具，则可以尝试Google Place API 。
不，绝对不是。 如果你比较美国和日本的地址的工作方式，你会发现这是不可能的。
更新：
再想一想，什么都可以做，但是有一个权衡。
一种方法是使用地址和地址属性表对地址和地址属性表进行build模，在它们之间build立1：m的关系，任何东西都可以build模。 address_attribute表将有一个pk，一个名称，一个值，和一个fk，指向它的父地址的pk。 这几乎就像使用名称，值对的地图。
每次你想要一个地址时，权衡就必须join。 您还必须询问address_attributes的名称，以确定每次处理的内容。
另一种方法是对地址在世界各地如何build模进行更全面的研究。 在一个面向对象的世界里，你可能需要一些西方地址类（street1 / street2 / city / state / zip）和其他日本，中国的地址空间。 然后你将有一个主地址表和子表与其他types的1：1关系。
亚马逊或eBay如何做到这一点？ 他们运送国际。 他们有地区特定的UIfunction吗？ 我只使用美国语言环境。
你的devise应该强烈地依赖于你的目的。 有些人已经发布了如何构build数据。 所以如果你只是想发个邮件给别人的话，就可以了。 如果你想使用这些数据进行导航，事情就会变得复杂起来。 汽车导航将需要额外的结构来包含交通信息（例如单向道路），而步行导航将需要大量额外的数据。 这里是一个小例子：在我的城市，我的邻居在公园附近。 公园旁边是前机场（实际上是欧洲最古老的机场之一）变成了航空博物馆。 航空博物馆旁边是一个商业园。 博物馆的街道数是39，而商业园区的数字是39A。 所以看起来39和39A是接近的 – 但是从一个走到另一个需要大约一英里（如果开车的话更长）。
这只是我的一个小例子，我想你可能会发现很多例外（特别是在每个国家的农村或偏远地区）。
