数据库设计：两种数据存储关联方法的术语及优劣对比

一、两种方法的专业术语 #

• 方法1：父表持有子表外键的关联模式，属于非范式化设计——父表直接存储所有关联子表的主键，将多个一对一关系的引用集中在父记录中。
• 方法2：子表持有父表外键的标准关联模式，是关系型数据库中遵循第三范式（3NF）的经典设计，适配一对一或一对多的关联场景。

二、各自的优缺点 #

方法1（父表存子表外键） #

优点

• 关联关系直观：查看父表就能直接知晓该记录关联的所有子表对象，无需额外查询子表。
• 快速获取关联入口：一次查询父表即可拿到所有子表的ID，后续可直接定位到对应子数据。

缺点

• 违背第三范式：父表存储了与自身核心属性无关的子表引用，存在更新风险——比如子表记录删除后，父表对应ID字段会变为无效值，需手动同步维护。
• 扩展性极差：新增关联表时必须修改父表结构，添加新的外键字段，对在线系统影响极大。
• 不支持一对多：若一个父记录需要对应多个子记录（比如一个人有多个手机号），父表无法存储多值，只能拆成PhoneID1、PhoneID2这类字段，导致表结构臃肿。

方法2（子表存父表外键） #

优点

• 符合范式要求：数据无冗余，外键约束可保证关联关系的一致性，删除/更新子表或父表时能自动维护数据完整性。
• 扩展性强：新增关联表只需在新表中添加父表主键作为外键，完全无需修改父表。
• 天然支持一对多：比如一个人有多个手机号，只需在Phone表中插入多条带相同PersonID_PK的记录即可，表结构无需调整。

缺点

• 查询关联数据需多表操作：要获取父记录的所有子数据，需执行JOIN或多次单表查询，逻辑比方法1稍复杂。
• 无法直接从父表看到关联关系：必须查看子表的外键字段，才能知晓哪些子记录属于某个父记录。

三、哪种查询速度更快？ #

速度差异取决于具体场景：

• 如果是固定一对一关联，且每次都要查询父记录+所有子表单条数据：方法1更快，一次查父表拿到所有子ID，再分别查询子表即可，避免了子表的WHERE过滤开销。
• 如果是只查部分子表数据，或存在一对多场景：方法2更快。方法1无法处理多值关联，会导致查询逻辑混乱；而方法2的子表外键可建索引，通过WHERE PersonID_PK = ?能快速过滤出目标数据，JOIN操作的效率也更稳定。
• 长期来看，方法2的性能更可控：方法1的父表多外键字段建索引会增加存储和写入开销，数据量增长后性能下降明显；方法2的子表索引维护成本低，查询效率随数据量增长的衰减更平缓。

四、选择依据：必须结合场景决定 #

选哪种设计核心看以下几个维度：

1. 关联关系类型：如果是绝对的一对一、且关联表数量永远不会变，方法1可以凑合用；只要有一丝一对多的可能，必须选方法2。
2. 扩展性需求：未来可能新增关联表的场景，方法2是唯一可行方案——方法1改表结构的风险太高，线上系统根本经不起频繁变更。
3. 数据操作频率：如果以查询父+全量子数据为主、写入更新极少，方法1能提升查询效率；如果写入更新频繁，方法2的事务一致性和维护成本低得多。
4. 数据完整性要求：金融、政务这类对数据一致性要求极高的场景，必须用方法2，外键约束能避免无效引用；方法1靠人工维护很容易出数据问题。

内容的提问来源于stack exchange，提问作者Code Novice