不在Address表加GroupId列实现Group-Address一对多关联咨询

你提出的新增中间表实现关联的思路是可行的，但仅给GroupId加唯一约束的配置是错误的，调整约束位置后就能完全满足「不在Address表新增GroupId列、实现Group到Address一对多关联」的要求，同时还能很好适配Address同时关联Person的业务场景。

核心设计逻辑 #

你提到的类多对多中间表方案，本质是把原本存在于Address表的外键关联上移到独立中间表，避免修改Address表结构，只要约束配置正确，就能实现标准的一对多关系。

中间表结构与正确约束配置 #

新增GroupAddress中间表，仅保留两个关联字段即可，不需要额外业务字段：

GroupId | AddressId

约束规则如下：

• 两个字段分别创建外键，关联Group表的Id主键、Address表的Id主键，避免无效关联ID
• 给AddressId字段添加唯一约束：这是实现一对多的核心，保证同一个Address记录只能关联到一个Group，不会出现一个地址同时归属多个Group的脏数据
• 不要给GroupId添加唯一约束：如果给GroupId加唯一约束，同一个Group只能关联一条Address记录，会把关系变成Group和Address的一对一，完全不符合一对多的需求。

举个合法的表数据示例：

GroupId | AddressId
1       | 2
1       | 5
2       | 7

示例中GroupId=1关联了2、5两个地址，满足一个Group对应多个地址的要求；因为AddressId有唯一约束，不会出现AddressId=2同时绑定GroupId=1和GroupId=2的情况，保证关系正确性。

适配Person关联的扩展方案 #

由于你需要让Address同时支持关联Person记录，这套中间表方案的扩展性远好于在Address表加可空外键的方案：

• 后续实现Person到Address的一对多关联时，只需要新增PersonAddress中间表，结构和约束逻辑和GroupAddress完全一致：关联PersonId和AddressId，给AddressId加唯一约束即可
• 这种设计不会出现「同一条Address记录同时填了GroupId和PersonId、两个关联字段都为空」的脏数据问题，后续如果要新增其他关联Address的主体（比如部门、商户等），只需要新增对应中间表，不需要修改Address表的原有结构。

• 给中间表的GroupId、AddressId字段都加上普通索引，关联查询的性能和直接在Address表加外键的方案几乎没有差异
• 如果后续业务调整为一个Address可以同时归属多个Group/Person，只需要删掉对应中间表上AddressId的唯一约束，就能直接切换为多对多关系，不需要重构表结构

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