美国邮政地址的标准化（地址、县、市、州、邮政编码）？

Question

在过去的几年里，我一直试图了解哪种方式适合存储地址。我一直在“一路规范化”，但也“尽可能地去规范化”，我只是无法决定什么对我的项目有好处。

很快，我的项目将涉及大量用户（10 万+），并且所有用户都将存储 1-3 个地址（个人、企业和计费）。这意味着我可以有 100k+ * 3 个地址记录。此外，我将通过邮政编码进行大量查找（获取将地址注册到邮政编码中的用户）。我只会有美国地址。

我对用户到地址表及其与我的项目的关系感到满意。然而，没有关系的表格让我发疯。

（我在图像中显示的表格是这样的，只是为了让我更好地了解我需要什么以及如何处理。我知道有很多冗余字段，所以请不要按原样接受它们。）

有没有人有关于如何设计的任何提示？
有没有人有大公司（UPS、USPS 等）使用的模式或类似模式的链接或其他内容？

Answer 1

我认为@datagod的答案很好，但我会根据你所说的要求稍微调整一下：

地址表

AddressLine1 varchar(255) -- If using SQL Server I would go with NVARCHAR instead. You don't seem to need unicode support but why not support it since things will often be converted to unicode in the application layer by default anyway, and storage is cheap.
AddressLine2 varchar(255)
City varchar(50)
ZipCodeID int -- FK to PostalCode table
County varchar(50)
State      varchar(50)

正如你所看到的，我的建议与@datagod 的非常相似。我改变了两件事：

1. Country因为你说你只需要美国的地址，所以我摆脱了FK。
2. 我做了ZipCode/ PostalCodeFK。我认为这将使您能够更有效地索引/查询邮政编码。

此外，我觉得您不需要上传邮政编码的外部主列表，除非您想将该列表用于数据验证目的...您可以在插入地址时检查该邮政编码是否存在并将其插入到邮政编码表（如果不存在）。这会增加一些插入开销，但我认为不会那么多，因为常见的邮政编码会很快插入。

如果您要搬到国际，那么我肯定会Country按照@datagod 的建议添加该表。

在这一点上，将数据库规范化为城市/县/街道等对我来说似乎有点矫枉过正，除非满足以下任何条件：

• 您发现自己经常通过这些数据点进行查询，并且会从索引/标准化中受益
• 您必须执行某种基于区域的安全性，即位于亚特兰大的销售人员无法访问这三个县之外的信息。
• 您希望使用这些列表作为数据验证，以确保人们不会向您提供错误的数据。（这看起来实施起来会很混乱，具体取决于您想要验证数据的程度。）
• 我没有想到的其他一些原因会导致进一步正常化，让你的生活更轻松。

我没有 @datagod 处理数百万条地址记录的经验，所以我的建议可能完全错误，但这是我会采取的方法。

编辑：现在有两个答案回避标准化邮政编码，所以我可能会忽略一个痛点，因为我还没有经历过。