目前我们存储的地址数据如下：
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），所有这些都会变得非常容易。
我已经提出了两个论点，为什么我们应该按原样保留它： 1.当您可以搜索JUST街道名称或数字等时，搜索会更容易。但我认为一个sql脚本沿着SELECT x FROM Address WHERE streetAddress LIKE“％ INPUT ％” ;当然它不是那么快，但它会起作用（并且该搜索的数据集仅在客户上比我们存储的所有地址的集合小得多）。
由于地址中存在无数例外，我已将它们全部存储为字符串。
所以我问，是否需要/想要分别存储街道地址部分？
答案 0 :(得分：4)
前一段时间我写了一篇关于此的博文。将每个数据存储在一个单独的字段中有很好的理由。尤其是对地址数据的验证。
当然，这取决于您所在的行业以及所使用的信息。如果无效的地址数据不会给公司造成任何损失，那么无论如何都要存储无效数据。请注意，尽管如此，您可能希望将此数据用于邮件，人口统计报告等。如果数据无效，则事后修复此数据并非易事。
这是我的博文：
http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html
另外，参考搜索“Where StreetAddress Like'％what％'”。如果您正在快速搜索自己的利益，这一切都很好，但当您尝试自动化依赖地址数据或甚至尝试删除重复项的系统部分时，请为用户提供自动建议等等等，性能降低到地址表越大它将变得无法使用的程度。
如果无效地址不是担心会给公司带来真正的现金，那么这不是问题 - 但是，如果您没有将这些地址用于任何有利于财务（或可能在未来），那你为什么要首先存储这些信息呢？
@Snorfus 啊，你必须在大草原。我忽略了包括在我的博客文章中发布关于土地描述的内容，但这是我正在考虑的后期帖子。
法律细分（LSD）主要用于Oil＆amp;阿尔伯塔省，萨斯喀彻温省和马尼托巴省的天然气和其他主要资源产业（尽管它们也存在于北美地区的部分地区，但它们并没有如此普遍使用）。它们都采用相同的格式：Section，Township，Range，Meridian。例如：
SE 28-12-17-W5
这是第5个子午线以西17区第12区第28区的东南角。
您可以简单地使用单个字段并使用正则表达式对其进行解析，或将其分解为包含LSD细分的单独字段。在性能方面，在SQL Server中运行正则表达式会很麻烦。我对它的看法与通常的地址数据相同，因为每个数据都是一个独立的数据，它们应该存储在不同的字段中。但是，鉴于大多数此类地址数据不被公众用来代替街道地址，我可能会建议设计一些可以将这些信息分开的东西（但是链接到您的主要地址数据。然而，鉴于土地描述/ LSD也是每个加拿大地址的一部分，我可能会将其存储在我的主地址表中，具体取决于数据库的目标受众。
以下是关于艾伯塔省土地资源系统细分的帖子：
http://www1.agric.gov.ab.ca/%24department/deptdocs.nsf/all/agdex10302
你经常会在Oil＆amp; amp;至少气体（这是我经验的大部分来源）是工人通常只会参考LSD的前两部分 - 即12个中的28个，或16个中的43个。其余的LSD是由地址的地点 - 即大草原，福克斯克里克，沃尔夫湖等。
答案 1 :(得分：2)
我曾经认为这是一个好主意，直到部署了我的应用程序并且有不断变化的请求流。那时，我住在加拿大安大略省，我以为我知道标准地址是什么样的。直到某个客户的地址合并了P.O.箱子和街道地址合而为一。然后，艾伯塔省的客户开始使用另一个答案中提到的结构化代码。然后，不列颠哥伦比亚省的地址是没有街道或街道号码，只有一个地点和隔间和农村路线。 C4，S16 RR7 Mountainville。然后与美国供应商一起，邮政编码规则就消失了。然后，偶尔的英国客户出现在数据库中，你认为你所知道的关于地址的一切都会消失。没有街道号码的建筑物名称，两个街道名称，两个城镇名称都在一个地址中！
Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom
这是一个组成的例子，但确实存在。英国人设法通过，因为每个本地公司都有一个最新的国家地址数据库，他们所需要的只是邮政编码和房屋名称或号码。其余部分由数据库填写。
在该地址的情况下，可能在Seething-under-Norton之间还有另一个Waverly Crescent，这就是为什么第二个街道名称。而且，诺森河下游是一个长期被纳入班伯里镇的村庄，所以两个名字都在地址中。在英国的地址中，你经常会找到不存在的城市。它们被认为是邮政城镇，因为它们只存在于邮政系统内。名称通常有历史基础。许多伦敦地址就像人们一次写伦敦，雷顿或南瑞斯利普或希灵顿一样。所有这些信件都能及时送达。
因此，除非您的软件功能是防止外部地址进入系统，否则请不要这样做！
顺便说一下，你提到用街道名称识别同一街道上的所有人。你有没有检查过丹佛科罗拉多州哪里有街道名称，这些名字会在一英里远的地方再次结束。我曾经迷失在利特尔顿（丹佛郊区）试图寻找某个地址，只是被告知我需要另一条在其他地方这样的街道。然后是英国人在每条道路上使用两个或更多名字的做法。例如，将有一条Homerton Road，然后命名为Marsh Hill，然后是Homerton High Street，然后是Urswick Road，然后是Lower Clapton Road，所有这些都在一两公里的范围内。更常见的是，在威克村将有一条诺顿路。如果您遵循它，在一两英里之后，您将注意到您现在在Wick Road，进入Norton村。
答案 2 :(得分：1)
在我看来，这样做有一些好处，但在我看过它的所有情况下，这样做的成本和复杂性都超过了可以忽略不计的好处。
至少你的问题是培训/强迫用户尊重你给他们的所有单独的字段，以一致的格式输入构成和解决的所有不同部分 - 大多数人只是没想到一个街道地址由多达5个不同的部分组成，很可能只是像往常一样输入。
因此，如果不是人们真正尝试使用该系统，那可能是一个好主意。
答案 3 :(得分：0)
在欧洲，街道地址通常是名称加上“数字”（其中数字可以是“3a”）。我已经看到了存储它们的数据库，原因只有一个：你可以在官方数据库中查找街道名称来验证它们（例如防止打字错误）。因此，对于这个用例，将可验证和不可验证的部分保存在不同的列中是有意义的。
我怀疑你是否有理由进一步分解它，除非你担心你可能会丢失信息。
答案 4 :(得分：0)
如果您遵循面向对象的方法来建模整个域，那么这样做会带来好处。你的问题让我想起了这个博客标题 March is not a number作为答案。关于街道和地址（“街道不是字符串”）可以说类似的东西。 SnOrfus在他的评论中指出了一个有效的问题。
答案 5 :(得分：0)
虽然独立存储地址的每个组成部分可能是有利的，但您必须权衡成本与业务需求和要求。如果您没有做任何与邮寄或运输相关的事情，那么它可能会过度使用并使您的架构的各个方面复杂化。此外，任何处理您的代码的人都可能无法理解正在发生的事情并且在没有意识到的情况下引入重大问题，从而破坏了数据库。
例如，在美国境内，以下是街道的“交付线”： 邮政信箱12345.
在这种情况下，“邮政信箱”实际上是街道名称，而12345是主要编号。正常的“格式化”和传统智慧表明，地址应首先列出主要号码，如“123 Main Street”。
如果您以标准方式重新格式化地址，则必须记住地址最初的显示方式。
这是地址验证和标准化的用武之地。至少在美国和其他一些国家，包括英国在内的现代国家，您的优势在于能够将地址提交给在线地址验证服务，该服务可以清理，标准化并验证您的地址。通常情况下，这些服务会返回邮件上应显示的地址以及地址的组成部分。如果您对组件有业务需求，则可以单独存储它们。否则，对地址验证Web服务的另一次调用应该在所需的时间再次产生组件。
为了充分披露，我是SmartyStreets的创始人。我们提供基于美国的address verification服务，其中包括CASS-Certified validation您的地址。如果您有任何问题，我们非常欢迎您亲自与我联系。