因为最近在做毕设的时候设计到好友模块，因为之后会有分享功能，是基于好友模块来分享的，所以首先就要攻克好友模块，才能做之后的分享功能，思考了一天的时候，也查了相关的前人思路，最后自己再总结一下，至于功能，自己已经通过SpringBoot+webSocket+mysql基本实现

具体功能:

1. 添加好友，待确认
2. 通过好友
3. 获取所有好友
4. 获取待确认的人
5. 删除好友
6. 修改好友备注

先说一下关于表的设计，我看了看前人的设计，有的人只设计了一张表，设置了一个status来表示其是待确认状态，还是是好友的状态，比如status=0表示未通过状态，status = 1 就是好友关系，但是我觉得一张表还是单作用的比较好，防止作用混乱，到后面自己都不知道这张表有多少被引用，而且待通过的量是一定不大的，每个人不可能有好几百个待通过的人，这是不符合逻辑的，即使你有100W个用户，每个用户封顶300好友，最多好友表也就是100W * 300的量，而待确认的表100W * 5 * 2就已经很夸张了.

所以在这里，我是设计了两张表，一张是friend_confirm表->待确认表，一张是friend表->真正成为好友的表.

friend_confirm：

字段	类型	备注
id	int	主键id
active_id	int	主动添加的用户id
inactive_id	int	被动添加的用户id
comment	varchar(1000)	添加时候的留言
create_time	datetime	创建时间
update_time	datetime	更新时间,比如a添加b，b一直不反应,a一直添加就更新

friend:

字段	类型	备注
id	int	主键id
user_id	int	主动添加的用户id
frd_id	int	被动添加的用户id
user_frd_remark	varchar(100)	user设置frd的备注,默认就是frd用户的昵称
frd_user_remark	varchar(100)	frd设置user的备注,摸摸人就是user_id对应的用户的昵称
create_time	datetime	创建时间
update_time	datetime	更新时间

• 添加好友的实现思路
  前端通过好友搜索栏，去搜索用户，根据手机号、昵称等来搜索，得到的用户，一定是存在的用户，那么在后面添加等就不用再次清洗错误数据，前端点击要添加的用户b，点击添加按钮后，触发后台服务，这个时候拿到主动添加的用户id，要添加的用户id(被动),以及留言,这里就不用检查是不是已经是不是好友了，如果是好友就不会有这个添加按钮，也就是之前已经过滤了一层，这个时候检查friend_confirm表，如果已经有了active_id = 主动添加的用户id inactive_id = 被动添加的用户，那么就更新，如果检查后发现friend_confirm表没有这个数据，那么就添加进去，添加成功后，再通过Websocket来通知被动添加的用户，如果现在被动添加用户在线，也就是可以拿到webSocket，那么就发送一个json给被动添加用户，前端拿到后就进行处理提示被动添加用户有新好友进行请求添加，如果被动添加的用户不在线，那么就不管，因为当一个用户第一次上线的时候都要请求一次待通过好友的接口，如果有新的就提示，不然就不处理

• 通过好友
  被动用户接受到新的好友提示后，去点击通过，还是拒绝，通过的话，就删除掉friend_confim表内 active_id = 主动添加id，inactive = 被动添加id 和 active_id = 被动添加id，inacitve_id=主动添加用户id，因为一旦通过，不论是谁先请求的，都将不存在这个确认关系，所有确认表内这两个人的关系都要清除掉，然后将 active_id对应到friend表的user_id,inactive_id对应到frd_id,并将comment也移动过，并默认两个人的备注为各自的昵称

• 获取所有好友
  获取所有好友，即可通过friend表内来查询可得，因为我们一条数据就表示了两者的相互关系，所以比如查id = 1001 的用户，他存在friend表的有时候是被动请求添加的，有时候是主动请求添加的，那么他们存在friend表内的列就不一样，但我们知道friend表内是一定没有重复行的。即可通过union all 来快速得到好友
  比如:

select user_id as friend_id from friend where frd_id = 1001
union all 
select frd_id as friend_id from friend where user_id = 1001

第一个select就表示 查找用户1001的朋友  情况是1001是被动添加的
第二个select就表示 查找用户1001的朋友  情况是1001是主动添加别人的

union all  将其汇总在一起

• 获取待确认的人
  获取待确认的人就是去请求待确认表的数据，也就是查inactive_id = id的时候

select active_id from friend_confirm where inactive = 1001 ;
查找别人主动添加1001，用户1001还未通过的用户

• 删除好友
  删除好友就是从friend表内删除即可，这个就不必多说，但是有一点注意，这个由于一行就表示了双反过的关系，所以，当要删除的时候，就是一方删除，另一方也会被删除.而不是微信那样的单删.