在 SQL 数据库中存储地址的最佳实践/标准

Question

我想知道在数据库中存储美国地址是否有某种“标准”？这似乎是一项常见的任务，应该有某种标准。

我正在寻找的是数据库表应该如何工作和交互的特定模式，已经是第三范式，包括数据类型（MySQL）。一个好的 UML 文档会起作用。

也许我只是懒惰，但这是一项非常常见的任务，我相信有人已经在某处发布了一种有效的方法来执行此操作。我只是不知道去哪里找，谷歌也没有帮助。请指点我的资源。谢谢。

编辑

---

虽然这是一个比较笼统的问题，但我想澄清一下我的具体需求。

地址将用于指定活动地点的道路地址。这些地址需要采用最易于分解和搜索的格式，并且还可以被我最终将我的数据源链接到的任何第三方应用程序使用。

还有。数据将在输入时进行地理编码（经纬度）并单独存储，因此它必须符合任何地理编码器/应用程序/库的（尚未确定的）协议。

Answer 1

有关国际地址，请参阅Universal Postal Union 的Postal Addressing Systems database。

对于美国地址，请参阅USPS Publication 28 "Postal Addressing Standards"。

USPS 希望将以下不带标点的地址组件连接在一行中：

• 门牌号
• 预定向（N、SE 等）
• 街道
• 后缀（AVE、BLVD等）
• 后向（SW、E 等）
• 单位（APT、STE等）
• 公寓/套房号

例如102 N MAIN ST SE APT B

如果您将整个地址行作为单个字段保留在数据库中，则输入和编辑很容易，但搜索可能会更加困难（例如，SOUTH EAST LANE 是街道EAST，如S EAST LN还是LANE 和SE LANE ST 一样？）。

如果您将地址解析到单独的字段中，搜索街道名称或公寓等组件会变得更容易，但您必须将所有内容附加在一起才能输出，您需要 CASS software 才能正确解析，以及邮政信箱、农村路线地址, 和 APO/FPO 地址有特殊的解析。

在该位置具有多个地址的物理位置可以是多单元建筑物，在这种情况下，单元后的字母/数字（如 APT 和 STE）指定地址，或者它是商业邮件接收机构（例如，UPS 商店) 并附加一个邮递/私人邮箱号码（如100 MAIN ST STE B PMB 102），或者它是一家有一个 USPS 投递点的企业，邮件在 USPS 投递后路由（这通常需要公司可能需要的单独的 mailstop 字段，但 USPS 赢了'不想在地址行上）。

拥有多个实际地址的联系人通常是拥有街道地址和邮政信箱的企业或个人。请注意，每个地址都有不同的邮政编码是很常见的。

很典型的情况是，一项业务交易可能有一个送货地址和一个帐单地址（同样，使用不同的邮政编码）。我为每个地址保留的信息是：

• 名称前缀（DR、MS 等）
• 名字和首字母
• 姓氏
• 名称后缀（III、PHD 等）
• 邮件停止
• 公司名称
• 地址（美国每个 Pub 28 仅一行）
• 城市
• 州/省
• 邮政编码
• 国家

我通常会在人名和公司之间的某处打印邮件站点，因为国家/地区包含州/邮政编码，其中包含城市，地址包含包含公司的地址，该地址包含包含该人的邮件站点。我使用 CASS 软件在输入或编辑地址时验证和标准化地址。

Answer 2

首先，作为一个大部分时间都在处理地址的人，从数据的角度来看，他们很难管理。

如果你问 5 个人他们住在哪个地址；你会发现你得到了 5 个不同的答案。虽然你和我可以看出 123 Main Street Apt 1 和 Apt 1 123 Main Street 都是同一个地址，数据库程序会有挑战。

如果您使用以美国为中心的地址，几乎任何供应商提供的 CASS 认证软件都会相当好地标准化您的地址。我会推荐一个简单的格式如下：

• 地址 1
• 地址 2
• 地址 3
• 城市
• 状态
• 邮编
• Zip+4（我会携带这个，以便在检查重复项时更容易查找）

但是，如果您想要一个通用地址，我会查看 IdeaAlliance 的 ADIS 标准。该标准可用于将几乎任何国家/地区的地址分解（解析）为相关部分。然后可以使用基于万国邮政联盟标准（UPU S42 国际邮政地址组件和模板标准）的模板/组件将它们重新组合在一起。

这种格式的最大优点是可以输入邮政数据库（如 CASS）中不存在的地址并将其存储为单独的部分。

Answer 3

Verysimilarquestionshave之前被问过。

地址很乱——充其量。

这部分取决于您想对地址做什么。如果您打算使用它们将东西邮寄给人们，那么您只需要以方便的形式记录将出现在地址标签上的图像。如果你要分析地址，你必须更加努力。

请记住，第一次与美国以外的人打交道时，以前的所有规则都会误入歧途。您可能仅限于美国，但请注意。

Answer 4

我不久前研究过这个，但是是国际地址。我没有发现太多达成共识的方式。但是，对于美国，我找到了简洁命名的美国大道、地标和邮政地址数据标准（草案）：

http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/index_html

我不认为它们实际上提供了任何特定的数据库架构想法，但这可能是一个很好的起点。

Answer 5

首先，存储地址的“最佳”方式很大程度上取决于它的使用方式。它只是供参考还是搜索说城市？你打算处理信封吗？您是否要与 FedEx 或 UPS 等运输系统集成？你会存储非美国地址吗？一旦您进入与已发布的东西集成的领域，您应该开始查看CASS。这是处理 USPS 地址的规范。有一些经过 CASS 认证的应用程序将存储和验证地址。因此，第二个最佳实践是尽量避免重新发明轮子，看看是否有一个系统可以解决你的问题，特别是如果你要走向国际。您想利用这样一个事实，即其他人已经制定了有关如何正确有效地为世界上许多国家/地区存储地址的所有详细信息，而不必自己进行调查。

Answer 6

我以前曾尝试过这样做，我发现this document 可以为您提供一些指导。我最终搁置了我的架构，因为我的应用程序确实必须处理国际地址。