如何为评论类Web应用设计User、Friends、Review表的关联关系

核心关联结论先行 #

• 你判断的用户与评论1:n关联是完全正确的。
• 好友与用户的关联不适合设置为1:n，好友本质是用户与用户之间的多对多关系，Friends表应当作为两者的中间关联表使用。

各表详细设计与关联规则 #

User表（用户主表） #

作为所有关联的核心主表，存储用户基础属性：

• 主键 id
• 其他业务字段：用户名、头像、注册时间等

Friends表（好友关联中间表） #

用于存储两个用户之间的好友关系，两个外键均关联User表主键：

• 可选主键 id
• 核心关联字段 user_id：发起好友申请的用户ID，外键关联User.id
• 核心关联字段 friend_id：被添加的好友用户ID，外键关联User.id
• 业务字段：status（好友状态：待审核/已通过/已拒绝等）、create_time（添加时间）
• 可新增user_id + friend_id联合唯一索引，避免重复添加同一好友

补充：如果你的业务是双向好友无需二次确认，添加好友时可同时插入(A的ID,B的ID)、(B的ID,A的ID)两条记录，也可以仅插入一条，查询时做双向匹配即可。

Review表（评论表） #

存储所有用户发布的评论，和User表为1:n关联：

• 主键 id
• 核心关联字段 user_id：评论发布者ID，外键关联User.id
• 业务字段：target_id（评论接收目标ID，比如用户主页ID、动态ID等，可根据你的业务扩展）、content（评论内容）、create_time（发布时间）
• 可选冗余字段 is_friend_review：标记该评论是否是目标用户的好友发布，避免每次查询都关联好友表校验，提升性能

业务规则适配说明 #

针对你提到的「好友和普通用户均可以发布评论」的规则，不需要额外调整表结构，仅需要在业务逻辑层做对应处理即可：

• 发布评论时不需要做身份限制，所有登录用户都可以写入评论数据
• 查询评论时如果需要区分好友/普通用户评论，仅需要校验评论发布者的user_id和当前登录用户ID，是否在Friends表存在有效关联的好友记录即可

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