問題描述

最近打算實現(xiàn)一個通知系統(tǒng)。就像segmentfault差不多。比如那個人頂了你的答案。那個人采納了你的答案等。

而這些情況很多的時候如何去設(shè)計數(shù)據(jù)庫的字段呢？

保存的時候需要保存關(guān)系嗎？還是直接生成一個消息。顯示消息就行了？？

最近做這個。好迷茫的感覺

問題解答

可以使用 redis 的集合.

首先設(shè)置各種事件,比如0:關(guān)注1:采納2:贊3:邀請

redis 中每個人的有一個集合. uid 為集合名

假設(shè)有如下事件:1.用戶 A 贊了你在某個題目下的回答.2.用戶 B 邀請你回答某個問題

redis集合中就保存:0:Auid:問題id3:Buid:問題id

謝邀。本人也沒有相關(guān)經(jīng)驗。

建議保存關(guān)系，這對以后的數(shù)據(jù)分析比較有利。

redis是應(yīng)用層面的優(yōu)化，可以參考一下@悲慘的大爺 的答案。

SQL表有2種維度：第一種：只記錄用戶的關(guān)注, 采納, 贊, 邀請的數(shù)量

id(pk) | user_id | count | type(user_id + type)做唯一索引；優(yōu)點：簡單；缺點：只能看到用戶收到多少關(guān)注，但不知道收到誰的關(guān)注；

第二種：在第一種的基礎(chǔ)上把count字段換成another_user_id(這個名稱不好，隨便想的，不要參考)(user_id + another_user_id + type)做唯一索引；優(yōu)點：可以知道該用戶被誰關(guān)注了；缺點：表數(shù)據(jù)量增長會很快，容易上千萬甚至億級，而且不便統(tǒng)計（性能差）；

但第二種的缺點也不是不可解決，分庫分區(qū)、水平分表、另起一個表專門存儲統(tǒng)計數(shù)據(jù)等等，若干方法，等有需要的時候再考慮這個問題吧。

以上方案，視乎你們對業(yè)務(wù)的需求吧。

可能有更好的方法，此處僅供參考。