數據庫設計——評論回覆功能

原文連接:

　　http://blog.csdn.net/ztchun/article/details/71106117

　　

一、概述

評論功能已經成爲APP和網站開發中的必備功能。本文主要介紹評論功能的數據庫設計。

評論功能最主要的是發表評論和回覆評論（刪除功能在後臺）。評論功能的拓展功能體現有如下幾方面： 
（1）單篇文章的評論數量和信息展現； 
（2）從時間維度，按照時間倒敘的方式展現動態的用戶評論信息； 
（3）不一樣欄目，不一樣模塊，不一樣時間維度的評論排行展現； 
（4）精華評論的單獨推薦和聚合展現； 
（5）評論後直接分享到綁定的第三方平臺； 
（6）點贊數、回覆數等維度的排行等。

評論的後臺管理： 
（1）刪除； 
（2）推薦； 
（3）精華； 
（4）屏蔽，敏感關鍵字的庫的完善、自動屏蔽或者替換功能。

本篇文章主要分析幾種客戶端評論數據表的設計。

二、數據表設計

2.1 一問一答模式

(1)需求分析

大部分APP採用簡單的評論設計便可，便是一問一答模式，好比微信朋友圈的評論功能的設計。如：

A：今每天氣真好！
B @ A :今每天氣確實不錯！

這種設計簡單、直接，也知足了用戶評論、回覆的基本要求，對於沒有大量用戶評論的APP需求足夠。

（2）數據庫設計 
這種場景下通常評論較少，評論不活躍，能夠不區分評論和回覆，統一當作評論。區別是，有些評論是直接評論主題，而有些是@其餘用戶，使用一張表就能夠達到效果，評論表設計以下：

表字段	字段說明
id	主鍵
topic_id	主題id
topic_type	主題類型
content	評論內容
from_uid	評論用戶id
to_uid	評論目標用戶id

topic_type：爲了能複用評論模塊，咱們引入這個字段來區分主題的類別。

from_uid：表示評論人的id，經過該id咱們能夠檢索到評論人的相關信息。

to_uid 是評論目標人的id，若是沒有目標人，則該字段爲空

出於性能的考慮，每每咱們會冗餘評人的相關信息到評論表中，好比評論人的nick、頭像，目標用戶也是如此。 這樣一來咱們就只用查詢單表就能夠達到顯示的效果

有時，目標用戶有多個，那麼能夠將to_uid字段修改成to_uids，保存時用分隔符來分割用戶id，而目標用戶的信息再去查詢緩存或者數據庫。也能夠簡單的將多個目標用戶的信息一塊兒存成json格式，能夠應付簡單的展示需求。

2.2 評論爲主模式

(1)需求分析

若是以評論爲主的顯示模式，相似於下面的CSDN的評論顯示模式： 

這裏將評論分爲評論和回覆，全部評論均掛在評論下面，相似於樹狀結構。

（2）數據庫設計 
在以評論爲主的樹形顯示狀況下，數據庫的設計十分靈活，可使用單表，添加一個parent_id字段來指向父評論，須要嵌套查詢。

同時也能夠將評論拆分爲評論表和回覆表，評論掛在各類主題下面，而回復掛在評論下面。

評論表設計以下：

表字段	字段說明
id	主鍵
topic_id	主題id
topic_type	主題類型
content	評論內容
from_uid	評論用戶id

回覆表設計：

表字段	字段說明
id	主鍵
comment_id	評論id
reply_id	回覆目標id
reply_type	回覆類型
content	回覆內容
from_uid	回覆用戶id
to_uid	目標用戶id

因爲咱們拆分了評論和回覆，那麼評論表就再也不須要目標用戶字段了，由於評論均是用戶對主題的評論，評論表的設計更佳簡潔了。

回覆表添加了一個comment_id字段來表示該回復掛在的根評論id，這樣設計也是出於性能方面的考慮，咱們能夠直接經過評論id一次性的找出該評論下的全部回覆，而後經過程序來編排回覆的顯示結構。 經過適當的冗餘來提升性能也是經常使用的優化手段之一。

reply_type：表示回覆的類型，由於回覆能夠是針對評論的回覆(comment)，也能夠是針對回覆的回覆(reply)， 經過這個字段來區分兩種情景。

reply_id：表示回覆目標的id，若是reply_type是comment的話，那麼reply_id＝commit_id，若是reply_type是reply的話，這表示這條回覆的父回覆。

2.3 網易新聞蓋樓模式

（1）需求分析

這種場景中評論和回覆是同級顯示的，回覆不在顯示結構上不用掛在一個評論下面。 雙表的設計在這裏就不太合適了，由於涉及到評論和回覆的混排，使用雙表則會致使查詢的邏輯過於複雜。 因此建議仍是採用單表的設計，不區分評論和回覆會簡化應用層的邏輯。 咱們統一都當作評論，而有些評論是能夠引用其餘評論的。

（2）數據庫設計

本人推薦採用閉包表的設計，例如：

comment表設計：

表字段	字段說明
id	主鍵
topic_id	主題id
topic_type	主題類型
content	評論內容
from_uid	評論用戶id

parent_child表：

表字段	字段說明
id	主鍵
parent_id	父id
child_id	子id

comment表保存全部評論內容，而parent_children表則記錄評論表中各個評論的父子關係。

查詢時每每會按照時間排序，咱們能夠直接按id或者建立時間降序排列查詢comment表便可。 若是用戶想查詢一條評論的完整引用，則能夠經過parent_children來找到對應的路徑。

閉包表在查詢時很是方便，可是插入的性能稍差，由於除了插入評論表之外，還須要把該條評論全部的父子關係插入到父子關係表中。 插入性能會隨着評論層級的加深而線性降低。

三、數據庫優化

若是你的系統天天都會擁有成千上萬條評論，那麼單表的設計確定是不行，優化的方式有如下幾種思路。

（1）分庫分表。 分庫分表是最爲經常使用也最有效的優化方式，建議按照主題來分庫分表。 這樣同一個主題下面的評論就會落到同一張表裏，避免了跨表查詢。

（2）適當的數據冗餘。 若是你須要顯示評論人的相關信息，那麼在插入評論時就把這些信息寫入評論表中，避免屢次查詢。 實際上，若是是紀錄數據，均可以冗餘對應的數據信息，由於它們的數據的實時行和一致性要求並不高。

（3）附加冪。數據只容許單項操做。 由於從冪性的要求來講，每一個贊全都是一條記錄。 評論的贊數若是都從點贊表中統計得出，那麼性能開銷會十分巨大，並且點贊如此輕量級的一個操做必定會加重點贊表的競爭操做。 因此建議直接在評論表中添加一個like_count的計數器，該字段只增不減。客戶端，能夠設置取消效果。

（4）熱門評論加緩存。 相似於網易新聞的熱門評論，讀取頻度很是高，能夠專門開接口作緩存。