社交应用数据库中好友请求接受逻辑的最优实现方案咨询

嘿，咱们来拆解下你的社交应用好友请求实现问题，找出最适合你的方案～

首先得明确你的核心需求：你的初步思路里，点击「添加好友」就直接把请求状态设为accepted并同步双向好友记录，这看起来更像是无需对方确认的自动双向加好友逻辑；如果你的产品是需要对方同意才能成为好友的常规社交模式，那当前流程得调整。下面分场景给你最优方案：

场景1：无需确认，点击即成为双向好友 #

这种情况下，你完全不需要额外的request_table，直接优化现有user_friend表的操作就行：

• 当用户A（ID100）点击添加用户B（ID9）时，一定要在同一个数据库事务中插入两条记录：
  • user_id: 100, friend_id: 9
  • user_id: 9, friend_id: 100
• 用事务保证数据一致性，避免出现“我加了对方但对方好友列表没我”的单向好友问题
• 可以给user_friend表加个created_at字段，记录好友关系建立时间，方便后续做排序或统计

场景2：需要对方确认的好友请求流程（常规社交应用逻辑） #

这种场景下，请求记录表是必要的，但可以优化你的初步设计：

1. 优化请求表结构 #

建议把request_table的结构调整为：

• request_id（自增主键，方便后续操作单条请求）
• requester_id（请求发起方ID）
• accepter_id（请求接收方ID）
• status（状态：pending/accepted/rejected）
• created_at、updated_at（记录请求的时间节点）
• 给requester_id和accepter_id加唯一约束：UNIQUE(requester_id, accepter_id)，避免同一个用户重复发送好友请求

2. 优化流程逻辑 #

• 当用户A点击「添加好友」：向request_table插入一条status=pending的请求记录
• 当用户B在自己的请求列表点击「同意」：
  • 在同一个事务中，把request_table对应记录的status改为accepted
  • 同时向user_friend表插入两条双向好友记录：(100,9)和(9,100)
• 当用户B点击「拒绝」：只需把request_table对应记录的status改为rejected，无需操作user_friend表

更简洁的合并表方案（适合小型快速迭代应用） #

如果想减少表的数量，可以把好友关系和请求记录合并到一张user_relation表中：

• 字段：user_id、target_id、relation_type（可选值：friend/pending_request/sent_request）、created_at
• 逻辑：
  • 用户A发请求给B：插入(A,B,sent_request)和(B,A,pending_request)两条记录
  • B同意后：把这两条记录的relation_type都改成friend
• 这种方案只用一张表管理所有关系，但查询时需要注意筛选对应的关系类型，适合初期快速迭代的小型应用

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