好友模組實現原理 總結

2022-06-23 23:39:12 字數 2123 閱讀 2070

因為最近在做畢設的時候設計到好友模組,因為之後會有分享功能,是基於好友模組來分享的,所以首先就要攻克好友模組,才能做之後的分享功能,思考了一天的時候,也查了相關的前人思路,最後自己再總結一下,至於功能,自己已經通過springboot+websocket+mysql基本實現

具體功能:

新增好友,待確認

通過好友

獲取所有好友

獲取待確認的人

刪除好友

修改好友備註

先說一下關於表的設計,我看了看前人的設計,有的人只設計了一張表,設定了一個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

更新時間

通過好友

被動使用者接受到新的好友提示後,去點選通過,還是拒絕,通過的話,就刪除掉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 將其彙總在一起

select active_id from friend_confirm where inactive = 1001 ;

查詢別人主動新增1001,使用者1001還未通過的使用者