sql-非规范化地址

然而，我对此感到困惑的是——我应该把CityId、StateId和ZipCodeId放在Customer表中，还是应该把CityName、StateName和ZipCode放在Customer表中？是否应该在城市、州和zipcode表中将这些设置为引用外键？我是否应该完全去掉City表，只在ZipCode表和Customer表中重复City的名称？

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

---

原因：City和State表都是小表，加入它们不会造成性能问题，只需对它们进行索引，一切都会好起来。

我觉得您的设计不错-在customer表中保留完整地址。只需确保您允许在ZipCode表中输入多个具有相同ZipCode但不同城市的条目（即，不要使ZipCode.ZipCode具有唯一键）

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

---

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

名义上，customer表应仅包含街道地址和邮政编码ID（而不是城市或州）。注意，这种规范化方案的数据输入不一定是直接的；人们希望输入城市、州、邮政编码（或者仅仅是邮政编码），应用程序有责任正确地映射这些信息，并在必要时消除歧义

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

---

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

您还可以将USPS地址更正合并到您的应用程序中，以标准化并保持此信息的规范化。请参阅：

需要注意的一点是：可能有多个城市共享一个邮政编码（我现在正好住在这里）@mvp，谢谢！我将编辑我的问题。当你说完整地址时，你是指cityid、stateid、zipcodeid还是cityname、statename和zipcode？不是ID，而是字符串。如果zipcode表，我只会想到一个有用的应用程序——在输入zipcode后以输入形式自动建议cityname，但即使这样，仍然可以编辑城市名称（除非您有所有城市的综合列表），我不介意在customer表中存储城市、州和邮政编码——我的问题是它应该是cityid、stateid，zipcodeid或cityname、statename和zipcode？由您决定……如果存储字符串，应用程序将更易于编写。OTOH，你的交叉检查不会那么严格。严格的检查可能会让人恼火；地址的书写方式可能有各种各样的怪癖，除非您使用的是当前的USPS数据库，或者是最新的映射和地址细节，否则让人们输入他们认为正确的内容通常是明智的这是棘手的事情。我对过度规范地址处理持谨慎态度。这就是为什么我的回答是“名义上”开始的。

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

ZipCode Table - ZipCodeId, ZipCode, CityId, StateId