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

EN

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

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

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

• 地址线1-4
• Locality
• Region
• Postcode (或zipcode)
• Country

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

房屋编号(

• Building
• Sub-Building
• Premise number)
• Premise Range
• Thoroughfare
• Sub-Thoroughfare
• Double-Dependent Locality
• Sub-Locality

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

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

地点可能不明确，特别是地图地点和邮局地点之间的区别。邮局所在地是邮政机构认为的地方，有时可能是附近的大城镇。但是，邮政编码通常会解决那里的任何问题或差异，以便即使不使用官方邮政编码也可以正确递送。

看看Database Answers吧。具体地说，这涵盖了许多情况：

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

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

​

​

问问你自己，存储这些数据的主要目的是什么？您真的打算将邮件发送到该地址的人吗？跟踪人口统计数据、人口？能够要求呼叫者提供正确的地址作为一些基本身份验证/验证的一部分？以上都是什么？以上都不是?

根据您的实际需求，您将确定a)这并不重要，您可以选择自由文本方法，或者b)所有国家/地区的结构化/特定字段，或者c)国家/地区特定的体系结构。