类似Facebook好友请求功能的数据库设计方案咨询

嘿，这个思路方向是对的，但你的建表语句还有些关键细节没考虑到，咱们慢慢捋清楚：

单独用friend_request表存储待处理的好友请求，绝对是合理且行业通用的方案。把待确认的请求和已生效的好友关系（Friends_tbl）分开，既能避免数据混在一起导致查询混乱，也方便快速统计未处理请求、追溯请求历史这些操作。

你给出的这段建表SQL：

CREATE TABLE friend_request ( 
    request_id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
    from_uid INTEGER, 
    is_accepted INTEGER 
);

有几个致命的信息缺失，根本没法支撑业务逻辑：

• 没记录接收请求的用户（to_uid）：只知道是谁发起的请求，却不知道发给谁，这完全没法定位到用户X的待处理请求啊！
• is_accepted状态定义模糊：用整数没问题，但得明确取值含义（比如0=未处理，1=已接受，2=已拒绝），不然时间久了谁都记不清数字对应啥状态。
• 缺少请求时间：加个request_time字段，既能按时间排序展示请求，也方便后续清理过期的无人处理请求。
• 没有防重复机制：同一个用户可能多次给另一个人发请求，得给from_uid和to_uid加联合唯一约束，避免重复创建请求。

我给你调整了一下，补上这些必要的内容：

CREATE TABLE friend_request ( 
    request_id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
    from_uid INTEGER NOT NULL, 
    to_uid INTEGER NOT NULL, 
    is_accepted INTEGER DEFAULT 0 CHECK (is_accepted IN (0, 1, 2)), -- 0=未处理,1=已接受,2=已拒绝
    request_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (from_uid) REFERENCES users(uid),
    FOREIGN KEY (to_uid) REFERENCES users(uid),
    UNIQUE(from_uid, to_uid)
);

当用户X接受Y的请求时，可以这么操作：

1. 先把friend_request表中对应（from_uid=1001，to_uid=X的uid）的记录，is_accepted更新为1；
2. 往Friends_tbl里添加好友关系——这里要注意，好友关系一般是双向的，所以通常要存两条记录：一条是X的uid关联Y的uid，另一条是Y的uid关联X的uid（如果你的Friends_tbl设计是单条记录标记双向，就按自己的逻辑来）；
3. 至于这条请求记录要不要删除，看业务需求：保留的话可以追溯历史请求，删除的话能减少表的冗余数据，两种都可行。

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