關於使用者關注粉絲表設計方案的思考

2021-09-14 05:00:14 字數 2673 閱讀 5415

欄位名

型別索引

註解id

primarykey()

user_id

integer()->unsigned()->notnull()

normal

使用者followed_user

integer()->unsigned()->notnull()

關注的人的id

status

smallinteger()->unsigned()->defaultvalue(1)

關注狀態:是否取消關注等

created_at

integer()->unsigned()->notnull()

normal

updated_at

integer()->unsigned()->notnull()

normal

使用者每關注乙個人,都會在表中新增一條資料

優點

1.設計簡單,方便查詢

2.可以區分關注的每乙個人進行特殊處理(例如,不同人的關注事件,是否互粉,特別關注等),方便擴充套件

3.好寫**。

缺點

當使用者量大時表資料量會非常龐大,因此必需要採用水平分表的方式將使用者分散到多個表。

例如,有10萬使用者,id為1~10000的使用者放在表1(follow_1), id為10001~20000的使用者放在表2(follow_2), 以此類推。

然而分表後又會面臨另乙個問題,當被關注者依照多個表反查自己的粉絲時將會非常麻煩。因此需要再建乙個粉絲表:

欄位名型別索引

註解id

primarykey()

user_id

integer()->unsigned()->notnull()

normal

使用者follower

integer()->unsigned()->notnull()

粉絲status

smallinteger()->unsigned()->defaultvalue(1)

關注狀態:是否取消關注等

created_at

integer()->unsigned()->notnull()

normal

updated_at

integer()->unsigned()->notnull()

normal

此資料表依然需要做水平分表處理。

欄位名型別

索引註解

idprimarykey()

user_id

integer()->unsigned()->notnull()

唯一使用者

followed_user

text

關注的人

follower

text

粉絲created_at

integer()->unsigned()->notnull()

normal

updated_at

integer()->unsigned()->notnull()

normal

以json格式記錄每個使用者關注的人和粉絲

優點

1.每個使用者只有一條記錄

2.方便查詢

缺點

1.當粉絲數或關注的人數過大時,followed_user 和 follower 欄位的資料長度會非常大,當使用者關注的人或者粉絲數達到十萬級別時,一條資料的資料量將會達到 兆 級別,將會極大地降低mysql的查詢和php資料處理的效率。

2.每一次使用該錶時都要將整條資料取出進行計算,對資源耗費太過嚴重。

使用redis的hash資料型別

redis hash是乙個string型別的field和value的對映表。

redis 中每個 hash 可以儲存 232 - 1 鍵值對(40多億)。

每個使用者分一張hash表,表名為使用者id(可加字首或字尾)

使用者每關注乙個人,便在hash表中新增一條資料

field: 關注使用者的id

value:關注時間

field

value

21483423443

31483423445

131483423440

......

field

value

11483423443

51483423445

101483423440

......

優點

1.查詢處理速度快。

缺點

1.消耗伺服器記憶體和cpu。最好使用一台單獨的伺服器來執行 redis

2.資料查詢,處理不如關係型資料庫靈活。

3.開發步驟複雜,學習成本高。

微博關係服務與redis的故事

乙個微博資料庫設計帶來的簡單思考(使用mysql)

論壇相關討論

使用者中心,關注使用者動態的功能,資料庫結構是如何設計的?

微博關注是根據什麼來知道你關注我,我關注你了?資料庫怎麼設計?

使用者中心,關注使用者動態的功能,資料庫結構是如何設計的?

sns,微博 好友關注和推送功能的資料庫設計是怎麼實現的底層設計?

資料庫表的設計方案

1 一對多或者多對一的物件在資料庫裡面如何設定表來儲存資料原理解說當在程式中物件的關係為1對多或者多對1的關係時,在資料庫裡面我們怎樣設計表來儲存資料呢?1 首先分別設計兩個表來儲存兩個物件的基本屬性,不用管他們之間的關係 2 然後再在多的物件的表裡面設定外來鍵來描述兩個表之間資料的關係即可滿足需求...

使用者簽到的資料庫設計方案

初步設計了一下使用者簽到的設計方案,記錄下這種思路,以後可能需要完善。每月最多有31天,int32有32位,簽到與沒簽到只有兩種狀態,簽到用1來表示,未簽到用0來表示,因此可以用int32來表示使用者每月的簽到情況。資料庫表 sign record 的設計 列型別 描述 idint64 自增鍵use...

C C 中煉表的三種設計方案

1.一般做法,用具體資料結構封裝鍊錶。struct data 上邊這個例子,在data結構中有個next域,通過這個就可以組成乙個鍊錶,這個是我讀書時最常用的模式。缺點在於 每種具體的結構都要寫一遍鍊錶的增刪查改操作,重複了n多。2.stl的做法 用鍊錶封裝具體資料結構。struct data li...