数据库设置选中行最佳实践：用户主地址存储方案选型

嘿，这个问题在地址系统设计里挺常见的，我来帮你拆解下两种方案的利弊，再说说哪种更贴合最佳实践～

先直接给结论：方案二（在addresses表新增字段标记主地址）更符合数据库设计的最佳实践，下面详细说原因：

方案一：独立primaryaddress表的问题 #

• 维护成本高且冗余：额外的关联表意味着每次新增、修改或删除地址时，都要同步维护这张表的关联关系，不仅增加了代码复杂度，还容易出现遗漏操作的情况。
• 数据一致性风险：如果不小心在primaryaddress表中给同一个用户插入多条记录，就会出现“一个用户有多个主地址”的矛盾场景。虽然可以加唯一约束规避，但这又多了一层额外的校验逻辑。
• 查询效率偏低：要获取用户的主地址，必须做一次表关联查询，相比单表查询，性能和简洁度都差一些。

方案二：在addresses表新增标记字段的优势 #

• 逻辑简洁直观：所有地址相关的信息都存在同一张表，开发者一眼就能理解主地址的标记逻辑，不需要跨表溯源。
• 易保障数据一致性：可以通过唯一约束（比如UNIQUE(user_id, is_primary)，其中is_primary是布尔类型）强制每个用户最多只有一个主地址，从数据库层面直接杜绝了多主地址的问题。
• 查询高效便捷：获取主地址只需要一条简单的查询语句：SELECT * FROM addresses WHERE user_id = ? AND is_primary = 1，不需要关联其他表，性能更优。

补充优化建议 #

如果采用方案二，这些细节可以帮你做得更严谨：

• 给is_primary字段设置默认值为0（非主地址），避免新增地址时忘记标记状态。
• 加检查约束限制is_primary的取值只能是0或1（比如MySQL用CHECK(is_primary IN (0,1))）。
• 当用户切换主地址时，用事务包裹“将原主地址标记为非主地址 + 把新地址设为主地址”的操作，保证原子性，避免出现临时多主地址的情况。

内容的提问来源于stack exchange，提问作者Luke Brandon Farrell