1

目前我们像这样存储我们的地址数据：

string suiteNumber (ie. unit number)
string streetNumber (building number)
string streetName
string streetDirection (N/NW/S/etc.)
string streetType    (rd/st/ave/etc.)
// ... etc. (postal code/city/province/state/country

但是我遇到了（据我所知很常见）在处理和导入地址时解析前 5 个地址部分的问题。

我认为如果街道地址只是一个字符串（数据库中的 varchar），所有这一切都会变得容易得多。

对于为什么我们应该保持原样，我给出了 2 个论据： 1. 当您可以仅搜索街道名称或编号等时，搜索会更容易，但我认为 sql 脚本类似于SELECT x FROM Address WHERE streetAddress LIKE "% INPUT %"; 当然它没有那么快，但它会起作用（并且该搜索的数据集仅针对客户，比我们存储的所有地址的集合要小得多）。

  1. 目前我们有一个标记公寓的系统 - 如果您发现地址 A 的 1 个人是公寓，我们标记他们，它会搜索该街道编号/街道名称的所有其他人并标记他们（这有时很重要业务需求）

由于地址中有无数异常，我已经将它们全部存储为字符串。

所以我问，是否有特殊原因需要/想要单独存储街道地址部分？

4

6 回答 6

4

不久前，我写了一篇关于此的完整博客文章。将每条数据存储在单独的字段中是有充分理由的。尤其是对于地址数据的验证。

当然，这取决于您所在的行业以及信息的用途。如果无效地址数据不会让您的公司付出任何代价，那么请务必存储无效数据。请注意，尽管您可能希望将这些数据用于邮件、人口统计报告等。如果数据无效，事后修复它并非易事。

这是我的博客文章：

http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html

此外，参考搜索“Where StreetAddress Like '%whatever%'”。如果您正在为自己的利益进行快速搜索，这一切都很好，但是当您尝试自动化依赖地址数据甚至尝试删除重复的系统部分时，为用户提供自动建议等等等，性能下降到地址表越大将变得不可用的程度。

如果不担心无效地址会花费公司真正的现金，那么这不是问题 - 但是，如果您没有将地址用于任何有利于财务（或可能在未来）的事情，那你为什么要存储这些信息呢？

@Snorfus啊，你一定在大草原。我忽略了在我的博客文章中发布有关土地描述的内容，但这是我正在考虑在以后的文章中发布的内容。

法律细分 (LSD) 主要用于阿尔伯塔省、萨斯喀彻温省和马尼托巴省的石油和天然气以及其他初级资源行业（尽管它们也出现在不列颠哥伦比亚省的部分地区，但它们的使用并不普遍）。它们都采用相同的格式：截面、乡镇、范围、经络。例如：

SE 28-12-17-W5

这是第 28 节，第 12 镇，第 17 范围，第 5 次子午线以西的东南角。

您可以简单地使用单个字段并使用正则表达式对其进行解析，或者将其分解为包含 LSD 细分的单独字段。在性能方面，在 SQL Server 中运行正则表达式可能会很痛苦。我的看法与一般的地址数据相同，因为每条数据都是单独的唯一数据，它们应该存储在单独的字段中。然而，鉴于大多数此类地址数据不是被公众用来代替街道地址，我可能会建议设计一些东西，允许这些信息与您的主要地址数据分开（但链接到）。然而，鉴于土地描述/LSD 也是每个加拿大地址的一部分，我可能会根据数据库的目标受众将其存储在我的主地址表中。

这是一篇关于阿尔伯塔土地资源系统崩溃的帖子：

http://www1.agric.gov.ab.ca/%24department/deptdocs.nsf/all/agdex10302

至少在石油和天然气领域你会经常发现的一件事（这是我的大部分经验的来源）是工人通常只会提到 LSD 的前两个部分——即 12 个中的 28 个或 16 个中的 43 个。 LSD 的其余部分由地址的位置暗示 - 即 Grand Prairie、Fox Creek、Wolf Lake 等。

于 2009-10-26T18:21:35.713 回答
2

我曾经认为这是一个好主意，直​​到我的应用程序被部署并且源源不断的请求流进来以进行更改。当时，我住在加拿大安大略省，我认为我知道标准地址是什么样的。直到某个客户的地址将邮政信箱和街道地址合二为一。然后，阿尔伯塔省的客户开始带着他们在另一个答案中提到的结构化代码进来。然后不列颠哥伦比亚省的地址没有街道或街道号码，只有一个站点和隔间和农村路线。C4,S16 RR7 山城。然后与美国供应商一起，邮政编码规则被排除在外。然后偶尔出现的英国客户出现在数据库中，你认为你知道的关于地址的一切都消失了。一个没有门牌号的建筑物名称，两个街道名称，

Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom

这是一个虚构的例子，但它们确实存在。英国人之所以能过得去，是因为每家当地公司都有一个最新的国家地址数据库，他们所需要的只是邮政编码和房屋名称或号码。其余部分从数据库中填写。

在那个地址的情况下，诺顿下的沸腾可能还有另一个 Waverly Crescent，这就是第二个街道名称的原因。诺顿下的沸腾是一个很久以前并入班伯里镇的村庄，所以两个名字都在地址中。在英国地址中，您经常会看到不存在的自治市。它们被认为是邮政城镇，因为它们仅存在于邮政系统中。这个名字通常有历史依据。许多伦敦地址都是这样的，人们一次写伦敦，另一次写莱顿、南瑞斯利普或希灵登。所有的信件都会及时送达。

因此，除非您的软件的一个特性是它可以防止外部地址进入系统，否则不要这样做！

顺便说一句，您提到通过街道名称识别同一条街道上的所有人。您是否查看过科罗拉多州丹佛市，那里的街道名称会在一英里外结束并再次出现。我曾经在利特尔顿（丹佛郊区）迷路，试图找到某个地址，却被告知我需要另一条某处某处的街道。然后是英国的做法，即为每条道路使用两个或多个名称。例如，将有一条 Homerton 路，然后将其命名为 Marsh Hill，然后是 Homerton High Street，然后是 Urswick Road，然后是 Lower Clapton Road，所有这些都在一两公里的空间内。更常见的是，在威克村会有一条诺顿路。如果你跟着它走，一两英里后你会注意到你现在在威克路，进入诺顿村。

于 2009-10-26T20:03:54.290 回答
1

在我看来，这样做有一些好处，但在我看到它尝试过的所有情况下，这样做的成本和复杂性都超过了微不足道的好处。

并非最不重要的问题是培训/强迫用户尊重您提供给他们的所有单独字段，以便以一致的格式输入构成和地址的所有不同部分 - 大多数人只是不考虑街道地址最多由 5 个不同的部分组成，并且可能会像通常那样输入内容。

因此，如果不是为了实际尝试使用该系统的人们，它可能是一个好主意。

于 2010-12-07T13:58:51.347 回答
0

虽然它们可能是独立存储地址的每个组成部分的优势，但您必须权衡成本与您的业务需求和要求。如果您不做任何与邮寄或运输相关的事情，那么这可能是过度的，并且会使您的体系结构的各个方面显着复杂化。此外，处理您的代码的任何其他人可能不了解正在发生的事情并在没有意识到的情况下引入重大问题，从而破坏数据库。

例如，在美国，以下是一条街道的“送货线路”：邮政信箱 12345。

在这种情况下，“邮政信箱”实际上是街道名称，而 12345 是主要号码。正常的“格式”和传统观点认为地址应该首先列出主要数字，如“123 Main Street”。

如果您以标准方式将地址重新组合在一起，则必须记住地址最初的样子。

这就是地址验证和标准化的用武之地。至少在美国和包括英国在内的其他一些现代国家，您可以将地址提交给可以清理、标准化的在线地址验证服务。 ，并验证您的地址。通常，这些服务会返回应出现在邮件中的地址以及地址的组成部分。如果您对组件有业务需求，则可以独立存储它们。否则，对地址验证 Web 服务的另一次调用应在所需时间再次产生组件。

为了全面披露，我是 SmartyStreets 的创始人。我们提供基于美国的地址验证服务，其中包括对您的地址进行CASS 认证的验证。如果您有任何问题，我们非常欢迎您亲自与我联系。

于 2011-10-13T03:40:15.877 回答
0

在欧洲，街道地址通常是一个名称加上一个“数字”（其中数字可以是“3a”之类的东西）。我已经看到将它们分开存储的数据库有一个原因：您可以在官方数据库中查找街道名称以验证它们（例如防止拼写错误）。因此，对于这个用例，将可验证和不可验证的部分放在不同的列中是有意义的。

我怀疑你能找到进一步分解它的理由，除非你模糊地担心你可能会丢失信息。

于 2009-10-26T18:25:02.773 回答
0

如果您遵循面向对象的方法对整个域进行建模，这将是一个好处。你的问题让我想起了这个博客标题 三月不是一个数字作为答案。关于街道和地址可以说类似的东西（“街道不是字符串”）。SnOrfus 在他的评论中指出了一个有效的问题。

于 2009-10-26T19:58:06.390 回答