Cri*_*ian 5 normalization database-design denormalization
在过去的几年里,我一直试图了解哪种方式适合存储地址。我一直在“一路规范化”,但也“尽可能地去规范化”,我只是无法决定什么对我的项目有好处。
很快,我的项目将涉及大量用户(10 万+),并且所有用户都将存储 1-3 个地址(个人、企业和计费)。这意味着我可以有 100k+ * 3 个地址记录。此外,我将通过邮政编码进行大量查找(获取将地址注册到邮政编码中的用户)。我只会有美国地址。
我对用户到地址表及其与我的项目的关系感到满意。然而,没有关系的表格让我发疯。
(我在图像中显示的表格是这样的,只是为了让我更好地了解我需要什么以及如何处理。我知道有很多冗余字段,所以请不要按原样接受它们。)
有没有人有关于如何设计的任何提示?
有没有人有大公司(UPS、USPS 等)使用的模式或类似模式的链接或其他内容?
我认为@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)
Run Code Online (Sandbox Code Playgroud)
正如你所看到的,我的建议与@datagod 的非常相似。我改变了两件事:
Country
因为你说你只需要美国的地址,所以我摆脱了FK。ZipCode
/ PostalCode
FK。我认为这将使您能够更有效地索引/查询邮政编码。 此外,我觉得您不需要上传邮政编码的外部主列表,除非您想将该列表用于数据验证目的...您可以在插入地址时检查该邮政编码是否存在并将其插入到邮政编码表(如果不存在)。这会增加一些插入开销,但我认为不会那么多,因为常见的邮政编码会很快插入。
如果您要搬到国际,那么我肯定会Country
按照@datagod 的建议添加该表。
在这一点上,将数据库规范化为城市/县/街道等对我来说似乎有点矫枉过正,除非满足以下任何条件:
我没有 @datagod 处理数百万条地址记录的经验,所以我的建议可能完全错误,但这是我会采取的方法。
编辑:现在有两个答案回避标准化邮政编码,所以我可能会忽略一个痛点,因为我还没有经历过。