Customer Table - CustomerId, Street, City, State, Zipcode
ZipCode Table - ZipCodeId, ZipCode, CityId, StateId
但是，我对此感到困惑的是 - 我应该将 CityId、StateId 和 ZipCodeId 放在客户表中还是应该将 CityName、StateName 和 ZipCode 放在客户表中？并且应该将这些设置为引用城市、州和邮政编码表中的外键吗？我应该完全摆脱 City Table 并在 ZipCode 表和 Customer 表中重复城市名称吗？
如果可能有多个城市具有相同的邮政编码，那么更好的解决方案是拥有一个 City 表，其中有zipcode列（只有 varchar 或 int 列，没有外键）。在City表中，您保留State表中的外键。最后，您应该将CityId保留在Customer表中。
原因：City 和 State 表是小表，加入它们不会造成性能问题，只需在它们上创建索引，一切都会好起来的。
名义上，客户表应该只包含街道地址和邮政编码 ID（而不是城市或州）。请注意，这种标准化方案的数据输入不一定是直截了当的；人们会期望输入城市、州、邮政编码（或者可能只是邮政编码），并且应用程序有责任正确映射并在必要时消除歧义。
我也住在两个城市使用的邮政编码；他们甚至碰巧在不同的县，这导致我有时会问我住在哪个县。其中一个城市有多个其他邮政编码；另一个只有（部分）一个邮政编码。没有问题：对于同一个 ZipCode，您将有两个单独的 ZipCodeID 条目，每个城市一个。请注意，这意味着ZipCode 表中的 ZipCode 列上不会有唯一索引。
您会将 Zip+4 方案的 +4 存储在哪里？好问题！那属于街道地址。
你的设计对我来说看起来不错 - 在客户表中保留完整地址。只需确保您允许在 ZipCode 表中输入具有相同邮政编码但不同城市的多个条目（即不要使 ZipCode.ZipCode 成为唯一键）。
邮政编码仅与邮件系统有关，与政治界限完全无关。一些城市将覆盖多个邮政编码；一些邮政编码将覆盖不止一个城市。
当你打电话给保险公司并告诉他们邮政编码后，他们会给你非常糟糕的报价，这非常令人沮丧 - 仅仅是因为你似乎住在马路对面的不同城市，而那个城市的邮政编码完全相同，但犯罪情况很糟糕。
您还可以将 USPS 地址更正合并到您的应用程序中，以标准化并保持此信息标准化。见：https ://ribbs.usps.gov/index.cfm?page=aec