問題描述

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

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

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

最近做這個(gè)。好迷茫的感覺

問題解答

可以使用 redis 的集合.

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

redis 中每個(gè)人的有一個(gè)集合. uid 為集合名

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

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

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

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

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

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

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

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

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

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

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