sql - 非规范化地址答案

【问题标题】：sql - denormalize addresssql - 非规范化地址
【发布时间】：2012-12-07 07:15:03
【问题描述】：

Customer Table - CustomerId, Street, City, State, Zipcode

ZipCode Table - ZipCodeId, ZipCode, CityId, StateId

但是，我对此感到困惑的是 - 我应该将 CityId、StateId 和 ZipCodeId 放在客户表中还是应该将 CityName、StateName 和 ZipCode 放在客户表中？是否应该将这些设置为引用城市、州和邮政编码表中的外键？我应该完全摆脱 City Table 并在 ZipCode 表和 Customer 表中重复城市名称吗？

【问题讨论】：

需要注意的一点：有可能不止一个城市共用一个邮政编码（我现在恰好住在一个）
@mvp，谢谢！我将编辑我的问题。

标签： sql denormalization

【解决方案1】：

名义上，客户表应该只包含街道地址和邮政编码 ID（而不是城市或州）。请注意，这种标准化方案的数据输入不一定是直截了当的；人们希望输入城市、州、邮政编码（或者可能只是邮政编码），而应用程序有责任正确映射并在必要时消除歧义。

我也住在两个城市使用的邮政编码；他们甚至碰巧在不同的县，这导致我有时会质疑我住在哪个县。其中一个城市有多个其他邮政编码；另一个只有（部分）一个邮政编码。没有问题：对于同一个 ZipCode，您将有两个单独的 ZipCodeID 条目，每个城市一个。请注意，这意味着在 ZipCode 表中的 ZipCode 列上没有唯一索引。

您会将 Zip+4 方案的 +4 存储在哪里？好问题！那属于街道地址。

【讨论】：

我不介意在客户表中存储城市、州和邮政编码 - 我的问题是它应该是 cityid、stateid、zipcodeid 还是 cityname、statename 和 zipcode？span>
由您决定...如果您存储字符串，应用程序将更容易编写。 OTOH，您的交叉检查不会那么严格。严格的检查可能最终会惹恼人们；写地址的方式可能有各种各样的怪癖，除非您使用的是当前的 USPS 数据库，或者以其他方式了解地图和地址的细节，否则让人们输入他们的想法通常是明智的是正确的。这是棘手的事情。我对过度规范化地址处理持怀疑态度。这就是为什么我的回答从“名义上”开始。

【解决方案2】：

如果可能有多个城市具有相同的邮政编码，那么一个更好的解决方案是你有一个 City 表，你有 zipcode 列（只有 varchar 或 int 列，没有外国钥匙）。在 City 表中，您保留 State 表中的外键。最后，您应该将 CityId 保留在 Customer 表中。

原因：City 和 State 表是小表，加入它们不会造成性能问题，只需对它们进行索引就可以了。

【讨论】：

【解决方案3】：

您的设计在我看来不错 - 将完整地址保留在客户表中。只需确保您允许在 ZipCode 表中输入具有相同邮政编码但不同城市的多个条目（即不要使 ZipCode.ZipCode 成为唯一键）。

See here:

邮政编码仅与邮件系统有关，完全没有任何意义与政治边界有关。一些城市将覆盖更多不止一个邮政编码；一些邮政编码将覆盖不止一个城市。

当你打电话给保险公司并且告诉他们邮政编码后他们会给你一个非常糟糕的报价时，这非常令人沮丧 - 仅仅是因为你似乎住在马路对面的不同城市，而那个城市的邮政编码完全相同，但很糟糕犯罪情况。

【讨论】：

当您说完整地址时 - 您是指 cityid、stateid、zipcodeid 还是 cityname、statename 和 zipcode？span>
不是 id，而是字符串。如果邮政编码表，我只会想到一个有用的应用程序 - 在输入邮政编码后自动建议输入表单中的城市名称，但即便如此仍然可以编辑城市名称（除非你有所有城市的完整列表）

【解决方案4】：

您还可以将 USPS 地址更正合并到您的应用程序中，以标准化并保持此信息标准化。见：https://ribbs.usps.gov/index.cfm?page=aec

【讨论】：