數據庫設計實現評論回復功能

本篇內容主要講解“數據庫設計實現評論回復功能”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“數據庫設計實現評論回復功能”吧!

1、概述

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

評論功能最主要的是發表評論和回復評論（刪除功能在后臺）。評論功能的拓展功能體現有以下幾方面： 

（1）單篇文章的評論數量和信息展示； 

（2）從時間維度，按照時間倒敘的方式展示動態的用戶評論信息； 

（3）不同欄目，不同模塊，不同時間維度的評論排行展示； 

（4）精華評論的單獨推薦和聚合展示； 

（5）評論后直接分享到綁定的第三方平臺； 

（6）點贊數、回復數等維度的排行等。

評論的后臺管理： 

（1）刪除； 

（2）推薦； 

（3）精華； 

（4）屏蔽，敏感關鍵字的庫的完善、自動屏蔽或者替換功能。

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

2、數據表設計

2.1 一問一答模式

(1)需求分析

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

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

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

（2）數據庫設計 

這種場景下一般評論較少，評論不活躍，可以不區分評論和回復，統一看成評論。區別是，有些評論是直接評論主題，而有些是@其他用戶，使用一張表就可以達到效果，評論表設計如下：

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

from_uid：表示評論人的id，通過該id我們可以檢索到評論人的相關信息。

to_uid 是評論目標人的id，如果沒有目標人，則該字段為空

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

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

2.2 評論為主模式

(1)需求分析

如果以評論為主的顯示模式，類似于下面的CSDN的評論顯示模式： 

這里將評論分為評論和回復，所有評論均掛在評論下面，類似于樹狀結構。

(2)數據庫設計 

在以評論為主的樹形顯示情況下，數據庫的設計十分靈活，可以使用單表，添加一個parent_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）數據庫設計

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

parent_child表：

comment表保存所有評論內容，而parent_children表則記錄評論表中各個評論的父子關系。

查詢時往往會按照時間排序，我們可以直接按id或者創建時間降序排列查詢comment表即可。 如果用戶想查詢一條評論的完整引用，則可以通過parent_children來找到對應的路徑。

閉包表在查詢時非常方便，但是插入的性能稍差，因為除了插入評論表以外，還需要把該條評論所有的父子關系插入到父子關系表中。 插入性能會隨著評論層級的加深而線性下降。

3、數據庫優化

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

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

（2）適當的數據冗余。 如果你需要顯示評論人的相關信息，那么在插入評論時就把這些信息寫入評論表中，避免多次查詢。 實際上，如果是紀錄數據，都可以冗余對應的數據信息，因為它們的數據的實時行和一致性要求并不高。

（3）附加冪。數據只允許單項操作。 因為從冪性的要求來說，每個贊全都是一條記錄。 評論的贊數如果都從點贊表中統計得出，那么性能開銷會十分巨大，而且點贊如此輕量級的一個操作一定會加劇點贊表的競爭操作。 所以建議直接在評論表中添加一個like_count的計數器，該字段只增不減。客戶端，可以設置取消效果。

（4）熱門評論加緩存。 類似于網易新聞的熱門評論，讀取頻度非常高，可以專門開接口做緩存。

到此，相信大家對“數據庫設計實現評論回復功能”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！