城市拉链的最佳数据库设计;州表

时间:2010-01-05 16:31:10

标签: asp.net sql database oledb

我的申请需要参考地址。街道信息将与我的主要对象一起存储,但其余部分需要单独存储以减少冗余。我应该如何存储/检索ZIP,城市和州?以下是我的一些想法。

单表解决方案(不能做关系)

[位置] locationID locationParent(locationID为FK,状态条目为0) locationName(城市,州) locationZIP


两个表(具有关系,FK约束,参考完整性)

[状态] STATEID Statename的

[城市] cityID stateID(state.stateID的FK) 城市名称 邮政编码


三张桌子

[状态] STATEID Statename的

[城市] cityID stateID(state.stateID的FK) 的cityName

[拉链] zipID cityID(city.cityID的FK) zipName


然后我读了邮政编码和他们如何被分配。它们与城市没有特别的关系。有些城市有一个以上的ZIP(确定仍然可以使用)但是有些ZIP在一个以上的城市(哦快照)和一些其他ZIP(很少)在不止一个状态!此外,一些ZIP甚至与它们所属的地址的状态不同。似乎邮政编码用于识别承运人路线,一些偏远地区最好由邻近城市或州的邮局提供服务。

是否有人知道一个好的(不完美的)解决方案,考虑到这一点,以便在数据库增长时最大限度地减少差异?

5 个答案:

答案 0 :(得分:3)

实际上,USPS每年都会发布一些数据库(带有一个表),其中包含邮政编码,州和县以及州/县代码。我会调查一下。我有一个(过时的)副本。架构非常简单:


ZIPCODE nvarchar(5) not null
CITY nvarchar(50) null
STATE nvarchar(2) null
STATECODE nvarchar(50) null
COUNTY nvarchar(50) null
COUNTYCODE nvarchar(50) null
(见下文)

编辑:此外,我会允许您的用户添加新的邮政编码(包括城市和县等),因为邮政编码一直在添加..

http://www.usps.com/ncsc/addressinfo/addressinfomenu.htm

编辑: 实际上,我想我错了。我没有他们的数据库的官方副本..我下载了他们的一个示例文件,他们的架构似乎相当复杂。

答案 1 :(得分:2)

我不知道你是否正在国际化你的应用程序,但一般构造是这样的,与以下项目有一对多的关系:

国家
地区(州/省)
城市

这通常足以能够以有意义的方式过滤您的数据。相信我:你不想深入了解地理分区的技术细节。

对于地址,请将上面的数据加上街道地址,邮政编码(邮政编码的国际版本)等存储到您需要的分辨率。我说解决方案是因为你可以将地址字段拆分成公寓号,街道号,街道名称,街道方向等等 - 但这些数据可能取决于位置,所以如果你要去,我会避免这样做国际化您的应用程序。只有街道地址字段足够99.99%的时间。

答案 2 :(得分:2)

感谢所有回复。我想给一个评论&我的解决方案,有人感兴趣。问题是 “我应该如何存储/检索ZIP,城市和州?”

Jon Seigel给了我一个相当令人放心的答案: 国家 地区(州/省) 市 与一对多的关系。

我的理由是冗余和拼写错误。允许存储在地址记录中的任何城市和州列的任意自由输入打开了一系列查询问题。没有关系完整性可能允许不正确的城市到州。我只想以统一的方式存储位置,以便用户能够查找。

对于任何感兴趣的人,我的解决方案是:

[状态]。 STATEID; Statename的

[位置]。 locationID; stateID(FK); 城市名称; zipID

[location.stateID]是具有一对多到[state.stateID]的外键关系。我决定将ZIP与位置表保持一致,因为独特的ZIP与一个独特的城市没有直接关系。此外,似乎ZIP不是城市/州界限的基础,而是用于USPS目的,实际上表明可以跨越城市甚至州的承运人路线和邮递区。可以使用相同的城市名称和附加ZIP添加另一个位置记录。这种方式ZIP搜索可以导致所有城市&如果需要,城市搜索可以产生所有拉链。

答案 3 :(得分:1)

这取决于数据完整性,规范化是否更重要或性能。

然而,对于大多数应用程序,您真正想要的是一个家庭。因此,这些信息应与您的客户分开存储,这样您就可以代表住在同一家庭的多个客户。

家庭必须有街道地址,地址,城市,州/省,国家,邮政编码。

我不打算通过仅包含对城市的引用来规范化这一点(这可能是一个关键,因为可能有多个同名的城市),但是你应该存储一个单独的表格,包括城市,国家,邮政编码仅用于验证和完整性目的。

我会将这些外键作为家庭中的字段。

我曾与营销数据库合作,并开发了一个人工智能系统,用于为银行的住宅用途构建客户密钥和家庭密钥,这是主要问题之一。出于分析目的,我们需要将帐户汇总到客户级别,将客户汇总到家庭级别。所以你的代表应该支持这个以用于未来的分析目的。

答案 4 :(得分:0)

这种需求没有一个正确的模型 - 有几十个。要知道哪个最适合您,取决于一些其他信息,例如:

  • 表演&容量 - 什么是关于冗余的驱动因素?
  • 功能 - 将执行何种数据分析?
  • 历史数据 - 您是否必须维护旧数据?请注意,邮政编码会发生变化,这会使一些提供的解决方案无效
  • 国际化
  • 语言
  • 你有其他类型的地点吗?您可能需要一个更抽象的解决方案,可以整合物理电子位置 - 例如,如果您的用户想要选择首选联系方式等。
  • 您想要分享位置吗?
  • 是否保留或极有可能添加任何其他物理位置信息?像县,乡村,拉特&等等?