blocks|key|4911324|text|看看Database+Answers吧。具体地说，这涵盖了许多情况：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4911325|(所有可变长度字符数据类型)|4911326|AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails|code-block|syntax|javascript|4911327|​|4911328|📷|atomic|4911329|4911330|entityMap|0|LINK|mutability|MUTABLE|url|http://www.databaseanswers.org/data_models/customers_and_addresses/index.htm|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/1aa6dcd261b92955e1ddfdaae6b4ff40.gif|imageAlt^0|2|G|0|0|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|1A|8|@]|9|@]|C|$]]|$1|M|3|N|5|O|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|P|3|L|5|6|7|1F|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]|Y|$5|Z|U|10|C|$11|12|13|-4]]]]

Have a look at <a href="http://www.databaseanswers.org/data_models/customers_and_addresses/index.htm" rel="noreferrer">Database Answers</a>. Specifically, this covers many cases:

(All variable length character datatype)

<pre><code>AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails
</code></pre>

<a href="https://i.stack.imgur.com/VGzMy.gif" rel="noreferrer"><img src="https://i.stack.imgur.com/VGzMy.gif" alt="enter image description here"></a>

blocks|key|4911370|text|不，绝对不是。如果你比较一下美国和Japanese+addresses的工作方式，你会发现这是不可能的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4911371|更新：|4911372|转念一想，任何事情都可以做，但这是有权衡的。|4911373|一种方法是用address和address_attribute表对问题建模，它们之间有1:m的关系，任何东西都可以建模。address_attribute表将有一个pk、一个名称、一个值和一个指向其地址父级的pk的fk。这几乎就像使用具有名称、值对的Map。|4911374|权衡的是，每次您想要一个地址时都必须进行连接。您还必须询问address_attributes的名称，以确定每次处理的是什么。|4911375|另一种方法是对世界各地如何模拟地址进行更全面的研究。在面向对象的世界中，您可能有西方的Address类(street1/street2/city/state/zip)和日本、中国的其他类，只要需要，就可以划分地址空间。然后，您将拥有一个主地址表和其他类型的子表，它们之间具有1:1的关系。|4911376|亚马逊或eBay是怎么做到的？他们在国际上发货。它们是否具有特定于区域设置的UI功能？我只使用了美国语言环境。|4911377|entityMap|0|LINK|mutability|MUTABLE|url|http://www.worldwide-tax.com/japan/japaddresses.asp^0|H|I|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]]]

No, absolutely not. If you compare the way US and <a href="http://www.worldwide-tax.com/japan/japaddresses.asp" rel="nofollow noreferrer">Japanese addresses</a> work, you'll see that it's not possible.

UPDATE:

On second thought, anything can be done, but there's a trade-off. 

One approach is to model the problem with address and address_attribute tables, with a 1:m relationship between them, anything can be modeled. The address_attribute table would have a pk, a name, a value, and an fk that points back to its address parent's pk. It's almost like using a Map with name, value pairs.

The trade-off is having to do a JOIN every time you want an address. You also have to interrogate the names of the address_attributes to figure out what you're dealing with each time.

Another approach would be to do more comprehensive research on how addresses are modeled around the world. In an object-oriented world you might have the western Address class (street1/street2/city/state/zip) and others for Japan, China, as many as needed to tile the address space. Then you'd have a master Address table and child tables to the other types with a 1:1 relationship between them.

How does Amazon or eBay do it? They ship internationally. Do they have locale-specific UI features? I've only used the US locale.

blocks|key|1289266|text|这取决于您准备如何使用字段的自由格式。一个自由格式的地址字段显然总是可以的，但对缩小地理范围的帮助相对较小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1289267|你会遇到的问题是，不同国家之间的地理等级等级差异太大了。见鬼，有些国家甚至没有到处都有“街道地址”。|1289268|我建议你不要试图让它变得太聪明。|1289269|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Depends on how free-form you are prepared to go with the fields. One free-form address field will obviously always do, but be of relatively little help narrowing down geography.

The problem you'll have is that there is too much variation in the level of geographical hierarchy across countries. Heck, some countries do not even have 'street addresses' everywhere.

I recommend you don't try to make it too clever.

blocks|key|4066408|text|与这里的其他答案不同，我相信有一个结构化的地址数据库是可能的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4066409|出乎意料的是，我可以想到以下结构：|4066410|4066411|Country|unordered-list-item|4066412|Region+(州/+Province)|4066413|Locality+(城市/+Municipality)|4066414|Sub-Locality+(县/+locality)|4066415|Street|4066416|的其他分区|4066417|但是如何足够快地查询它呢？|4066418|我一直认为可以做到的一种方法是询问邮政编码(或邮政编码)，邮政编码因国家而异，但在国内是可靠的。|4066419|这样，您就可以围绕世界各地的邮局提供的信息构建数据结构。|4066420|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|19|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1A|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Y|$]]

Differently of other answers here, I believe it's possible to have an structured address database.

Just out of the hat, I can think of the following structure:

<ul>
<li>Country</li>
<li>Region (State / Province)</li>
<li>Locality (City / Municipality)</li>
<li>Sub-Locality (County / other sub-division of a locality)</li>
<li>Street</li>
</ul>

But how to query it fast enough?

One way I always think it can be accomplished is to ask for the ZIP Code (or Postal Code) which varies from country to country, but is solid within the country. 

This way you can structure your data around the information provided by the postal offices around the world.

blocks|key|4066462|text|Universal+Data+Model的Len+Silverston推荐了一个独立的GEOGRAPHIC+BOUNDARIES层次结构，并根据您愿意接受的简单STREET+ADDRESS+LINE或每个国家的衍生工具的自由形式程度而定。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4066463|entityMap|0|LINK|mutability|MUTABLE|url|http://www.univdata.com/^0|17|L|28|J|0|K|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]]|E|$]]|$1|F|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

Len Silverston of <a href="http://www.univdata.com/" rel="nofollow noreferrer">Universal Data Model</a> fame recommends a separate hierarchy of <code>GEOGRAPHIC BOUNDARIES</code> and depending on how much free-formed-ness you're willing to accept either simple <code>STREET ADDRESS LINE</code>s or per-country derivatives.

blocks|key|4066480|text|问问你自己，存储这些数据的主要目的是什么？您真的打算将邮件发送到该地址的人吗？跟踪人口统计数据、人口？能够要求呼叫者提供正确的地址作为一些基本身份验证/验证的一部分？以上都是什么？以上都不是?|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4066481|根据您的实际需求，您将确定a)这并不重要，您可以选择自由文本方法，或者b)所有国家/地区的结构化/特定字段，或者c)国家/地区特定的体系结构。|4066482|entityMap^0|F|2|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

Ask yourself what is the main purpose of storing this data? Do you intend to actually send mail to the person at the address? Track demographics, populations? Be able to ask callers for their correct address as part of some basic authentication/verification? All of the above? None of the above?

Depending on your actual need, you will determine either a) it doesn't really matter, and you can go for a free-text approach, or b) structured/specific fields for all countries, or c) country specific architecture.

blocks|key|4066548|text|对于国际地址，如果信息被分解为字段，则很难找到格式化信息的方法。例如，意大利语地址使用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4066549|<street+address>
<zip>+<town>+<region>
<country>|code-block|syntax|javascript|4066550|比如|4066551|Via+Eroi+della+Repubblica
89861+Tropea+VV
Italy|4066552|这与美国地址的顺序有很大不同-在第二行。|4066553|另请参阅SO问题：|4066554|4066555|How+many+address+fields+would+you+use+for+a+UK+database?|unordered-list-item|offset|length|4066556|Do+you+break+up+addresses+into+street+/+city+/+state+/+zip?|4066557|How+do+you+deal+with+duplicate+street+suffixes?|4066558|Best+practices+for+storing+postal+addresses+in+a+database+(RDBMS)?|4066559|4066560|也可以查看标签'postal-code‘。|4066561|4066562|编辑:地区和城镇的逆序-按UPU|4066563|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/373084/how-many-address-fields-would-you-use-for-a-uk-database|1|https://stackoverflow.com/questions/249156/do-you-break-up-addresses-into-street-city-state-zip|2|https://stackoverflow.com/questions/510078/how-do-you-deal-with-duplicate-street-suffixes|3|https://stackoverflow.com/questions/310540/best-practices-for-storing-postal-addresses-in-a-database-rdbms|4|https://stackoverflow.com/questions/tagged/postal-code|5|http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml^0|0|0|0|0|0|0|0|0|1K|0|0|0|1N|1|0|0|1B|2|0|0|1U|3|0|0|8|B|4|0|0|D|3|5|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1S|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1T|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1V|8|@]|9|@$S|1W|T|1X|1|1Y]]|A|$]]|$1|U|3|V|5|R|7|1Z|8|@]|9|@$S|20|T|21|1|22]]|A|$]]|$1|W|3|X|5|R|7|23|8|@]|9|@$S|24|T|25|1|26]]|A|$]]|$1|Y|3|Z|5|R|7|27|8|@]|9|@$S|28|T|29|1|2A]]|A|$]]|$1|10|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|2C|8|@]|9|@$S|2D|T|2E|1|2F]]|A|$]]|$1|13|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|2H|8|@]|9|@$S|2I|T|2J|1|2K]]|A|$]]|$1|16|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]|1E|$5|19|1A|1B|A|$1C|1F]]|1G|$5|19|1A|1B|A|$1C|1H]]|1I|$5|19|1A|1B|A|$1C|1J]]|1K|$5|19|1A|1B|A|$1C|1L]]|1M|$5|19|1A|1B|A|$1C|1N]]]]

For international addresses, it is remarkably hard to find a way to format the information if it is broken down into fields. As a for instance, an Italian address uses:

<pre><code>&lt;street address&gt;
&lt;zip&gt; &lt;town&gt; &lt;region&gt;
&lt;country&gt;
</code></pre>

Such as 

<pre><code>Via Eroi della Repubblica
89861 Tropea VV
Italy
</code></pre>

That is rather different from the order for US addresses - on the second line.

See also the SO questions:

<ul>
<li><a href="https://stackoverflow.com/questions/373084/how-many-address-fields-would-you-use-for-a-uk-database">How many address fields would you use for a UK database?</a></li>
<li><a href="https://stackoverflow.com/questions/249156/do-you-break-up-addresses-into-street-city-state-zip">Do you break up addresses into street / city / state / zip?</a></li>
<li><a href="https://stackoverflow.com/questions/510078/how-do-you-deal-with-duplicate-street-suffixes">How do you deal with duplicate street suffixes?</a></li>
<li><a href="https://stackoverflow.com/questions/310540/best-practices-for-storing-postal-addresses-in-a-database-rdbms">Best practices for storing postal addresses in a database (RDBMS)?</a></li>
</ul>

Also check out tag '<a href="https://stackoverflow.com/questions/tagged/postal-code">postal-code</a>'.

<hr>

Edit: Reverse order of region and town - per <a href="http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml" rel="nofollow noreferrer">UPU</a>

blocks|key|4911690|text|可以在一组标准字段中表示来自许多不同国家/地区的地址。被命名或编号的建筑物所在的命名通道(大道)的基本概念是相当标准的，有时在中国除外。其他接近通用的概念包括:命名居民点(城市/城镇/村庄)，这可以通用地称为一个地区；命名该地区并分配一个字母数字邮政编码。请注意，邮政编码也称为邮政编码，仅在某些国家/地区是纯数字的。如果你真的想成为通用的，你需要很多字段。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4911691|万国邮政联盟(万国邮政联盟)在一个standard+format中提供许多国家的地址数据。请注意，UPU格式包含整个国家/地区的所有地址(精确到可用字段精度)，因此它是关系型的。如果存储客户地址，其中只存储所有可能地址的一小部分，则最好使用包含所有字段和每行一个地址的单个表(或平面格式)。|offset|length|4911692|存储地址的合理格式如下：|4911693|4911694|地址线1-4|unordered-list-item|4911695|Locality|4911696|Region|4911697|Postcode+(或zipcode)|4911698|Country|4911699|4911700|地址线1-4可以包含以下组件：|4911701|房屋编号(+|4911702|Building|4911703|Sub-Building|4911704|Premise+number)|4911705|Premise+Range|4911706|Thoroughfare|4911707|Sub-Thoroughfare|4911708|Double-Dependent+Locality|4911709|Sub-Locality|4911710|4911711|通常只使用3条地址线，但这通常是不够的。当然，也可以要求更多的行来表示正式格式中的所有地址，但逗号始终可以用作行分隔符，这意味着仍然可以捕获信息。|4911712|通常情况下，数据分析将按地区、地区、邮政编码和国家进行，这些元素在用户输入数据时非常容易理解。这就是为什么这些元素应该存储为单独的字段。但是，不要强迫用户提供邮政编码或地区，它们可能不会在本地使用。|4911713|地点可能不明确，特别是地图地点和邮局地点之间的区别。邮局所在地是邮政机构认为的地方，有时可能是附近的大城镇。但是，邮政编码通常会解决那里的任何问题或差异，以便即使不使用官方邮政编码也可以正确递送。|4911714|entityMap|0|LINK|mutability|MUTABLE|url|https://upu.int/en/Postal-Solutions/Programmes-Services/Addressing-Solutions^0|0|H|F|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1U|8|@]|9|@$D|1V|E|1W|1|1X]]|A|$]]|$1|F|3|G|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|20|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|21|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|22|8|@]|9|@]|A|$]]|$1|P|3|Q|5|K|7|23|8|@]|9|@]|A|$]]|$1|R|3|S|5|K|7|24|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|26|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|27|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|K|7|28|8|@]|9|@]|A|$]]|$1|10|3|11|5|K|7|29|8|@]|9|@]|A|$]]|$1|12|3|13|5|K|7|2A|8|@]|9|@]|A|$]]|$1|14|3|15|5|K|7|2B|8|@]|9|@]|A|$]]|$1|16|3|17|5|K|7|2C|8|@]|9|@]|A|$]]|$1|18|3|19|5|K|7|2D|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|K|7|2E|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|K|7|2F|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2H|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1L|3|-4|5|6|7|2K|8|@]|9|@]|A|$]]]|1M|$1N|$5|1O|1P|1Q|A|$1R|1S]]]]

It is possible to represent addresses from lots of different countries in a standard set of fields. The basic idea of a named access route (thoroughfare) which the named or numbered buildings are located on is fairly standard, except in China sometimes. Other near universal concepts include: naming the settlement (city/town/village), which can be generically referred to as a locality; naming the region and assigning an alphanumeric postcode. Note that postcodes, also known as zip codes, are purely numeric only in some countries. You will need lots of fields if you really want to be generic.
The Universal Postal Union (UPU) provides address data for lots of countries in a <a href="https://upu.int/en/Postal-Solutions/Programmes-Services/Addressing-Solutions" rel="noreferrer">standard format</a>. Note that the UPU format holds all addresses (down to the available field precision) for a whole country, it is therefore relational. If storing customer addresses, where only a small fraction of all possible addresses will be stored, its better to use a single table (or flat format) containing all fields and one address per row.
A reasonable format for storing addresses would be as follows:
<ul>
<li>Address Lines 1-4</li>
<li>Locality</li>
<li>Region</li>
<li>Postcode (or zipcode)</li>
<li>Country</li>
</ul>
Address lines 1-4 can hold components such as:
<ul>
<li>Building</li>
<li>Sub-Building</li>
<li>Premise number (house number)</li>
<li>Premise Range</li>
<li>Thoroughfare</li>
<li>Sub-Thoroughfare</li>
<li>Double-Dependent Locality</li>
<li>Sub-Locality</li>
</ul>
Frequently only 3 address lines are used, but this is often insufficient. It is of course possible to require more lines to represent all addresses in the official format, but commas can always be used as line separators, meaning the information can still be captured.
Usually analysis of the data would be performed by locality, region, postcode and country and these elements are fairly easy for users to understand when entering data. This is why these elements should be stored as separate fields. However, don't force users to supply postcode or region, they may not be used locally.
Locality can be unclear, particularly the distinction between map locality and postal-locality. The postal locality is the one deemed by a postal authority which may sometimes be a nearby large town. However, the postcode will usually resolve any problems or discrepancies there, to allow correct delivery even if the official post-locality is not used.

blocks|key|1287866|text|你的设计应该强烈地依赖于你的目的。有些人已经发布了如何组织数据。因此，如果您只是想给某人发送s-mail，它就可以了。如果您想使用这些数据进行导航，事情就会变得复杂起来。汽车导航将需要额外的结构来包含交通信息(例如单向道路)，而步行导航将需要大量额外的数据。这里有一个小例子:在我所在的城市，我的社区就在公园附近。公园旁边是以前的机场(实际上，是欧洲最古老的机场之一)，变成了航空博物馆。航空博物馆旁边是一个商业园。博物馆的街道号码是39，商业公园的号码是39A。因此，39和39A可能看起来很接近-但从一个到另一个需要步行大约一英里(如果开车去的话甚至更长)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1287867|这只是我的城市的一个小例子，我想你可能会发现很多例外(特别是在每个国家的农村或荒野地区)。|1287868|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Your design should strongly depend from your purpose. Some people have posted how to structure data. So if you simply want to send s-mail to someone, it will do. Things begin to complicate if you want to use this data for navigation. Car navigation will require additional structures to contain traffic info (eg one-way roads), while foot navigation will require a lot of additional data. Here is small example: in my city, my neighborhood is near the park. Next to the park is former airfield (in fact, one of the oldest in Europe) turned into aviation museum. Next to aviation museum is a business park. Street number for museum is 39, while business park numbers start with 39A. So it may seem that 39 and 39A are close – but it takes about a mile to walk from one to another (and even longer if going by car) . 
This is just a small example taken from my city, I think you can probably find a lot of exceptions (especially in rural or wilder parts of every country).

blocks|key|848636|text|有时你能找到的最接近街道地址的地方是城市。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|848637|我曾经有一个项目，将印度所有的中学都放在谷歌地图中。我用Google+API写了一个很棒的程序，我想这会很简单。|848638|然后我从客户那里得到了数据。有些学校的地址是“市场对面，理发店旁边”或“靠近老公交车站”之类的东西。|848639|这让我的任务变得更加困难，因为不幸的是，Google+API不支持这种格式。|848640|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Sometimes the closest you can get to a street address is the city. 

I once had a project to put all the Secondary Schools in India in Google Maps. I wrote a spiffy program using the Google API and thought it would be quite easy. 

Then I got the data from the client. Some school addresses were things like "Across from the market, next to the barber" or "Near old bus stand". 

It made my task much harder since, unfortunately, the Google API does not support that format.

blocks|key|1289454|text|也许这是有用的：https://gist.github.com/259744为一个项目，我收集了世界上所有国家的信息，包括国际标准化组织代码，顶级域名，电话代码，汽车标志，长度和邮政编码的正则表达式。不幸的是，国家名称和评论只有德语。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1289455|entityMap|0|LINK|mutability|MUTABLE|url|https://gist.github.com/259744^0|8|U|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Maybe this is useful:
<a href="https://gist.github.com/259744" rel="noreferrer">https://gist.github.com/259744</a>
For a project I collected a table of informations about all countries of the world, including ISO codes, top level domain, phone code, car sign, length and regex of zip.
Country names and comments unfortunately only in German...

blocks|key|1287903|text|不，没有标准的编址方案。它通常因国家而异。甚至万国邮政联盟也在Adressing+the+world,+an+address+for+everyone上表示没有。最好的解决方案是使用由2/3个字母组成的国家代码标准，即ISO+3166，并按照国家的标准对待其他所有内容。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1287904|然而，如果你真的想在你的项目中使用易于使用的工具，你可以试试Google+Place+API。|1287905|entityMap|0|LINK|mutability|MUTABLE|url|http://www.upu.int/fileadmin/documentsFiles/activities/addressingAssistance/paperAddressingAddressingTheWorldAnAddressForEveryoneEn.pdf|1|http://www.iso.org/iso/country_names_and_code_elements|2|https://developers.google.com/places/documentation/^0|N|6|V|18|0|31|8|1|0|U|G|2|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]|$9|Z|A|10|1|11]]|E|$]]|$1|F|3|G|5|6|7|12|8|@]|D|@$9|13|A|14|1|15]]|E|$]]|$1|H|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]|R|$5|K|L|M|E|$N|S]]]]

No, there are no standard addressing scheme. It usually varies from country-to-country.
Even the Universal Postal Union said on <a href="http://www.upu.int/fileadmin/documentsFiles/activities/addressingAssistance/paperAddressingAddressingTheWorldAnAddressForEveryoneEn.pdf" rel="nofollow">Adressing the world, an address for everyone</a> that there is none. The best solution for this is to use the 2/3-letter country code standards known as <a href="http://www.iso.org/iso/country_names_and_code_elements" rel="nofollow">ISO 3166</a> and treat everything else by country's standards.

However, if you really are desperate to use easily accessible tools for your project, you can try <a href="https://developers.google.com/places/documentation/" rel="nofollow">Google Place API</a>.

I am a programmer and need a practical approach to storing street address structures of the world in a database. So which is the best and common database design for storing street addresses? It should be simple to use, fast to query and dynamic to store all street addresses of the world.

Is there common street addresses database design for all addresses of the world?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

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

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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