商品評論（評價）功能
1、概述
評論功能已經成為APP和網站開發中的必備功能。本文主要介紹評論功能的數據庫設計。
評論功能最主要的是發表評論和回復評論（刪除功能在后台）。評論功能的拓展功能體現有以下幾方面：
（1）單篇文章的評論數量和信息展示；
（2）從時間維度，按照時間倒敘的方式展示動態的用戶評論信息；
（3）不同欄目，不同模塊，不同時間維度的評論排行展示；
（4）精華評論的單獨推薦和聚合展示；
（5）評論后直接分享到綁定的第三方平台；
（6）點贊數、回復數等維度的排行等。
評論的后台管理：
（1）刪除；
（2）推薦；
（3）精華；
（4）屏蔽，敏感關鍵字的庫的完善、自動屏蔽或者替換功能。
本篇文章主要分析幾種客戶端評論數據表的設計。
2、數據表設計
2.1 一問一答模式
(1)需求分析
大部分APP采用簡單的評論設計即可，即是一問一答模式，比如微信朋友圈的評論功能的設計。如：
A：今天天氣真好！
B @ A :今天天氣確實不錯！
1
2
這種設計簡單、直接，也滿足了用戶評論、回復的基本要求，對於沒有大量用戶評論的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來找到對應的路徑。
閉包表在查詢時非常方便，但是插入的性能稍差，因為除了插入評論表以外，還需要把該條評論所有的父子關系插入到父子關系表中。 插入性能會隨着評論層級的加深而線性下降。
3、數據庫優化
如果你的系統每天都會擁有成千上萬條評論，那么單表的設計肯定是不行，優化的方式有以下幾種思路。
（1）分庫分表。 分庫分表是最為常用也最有效的優化方式，建議按照主題來分庫分表。 這樣同一個主題下面的評論就會落到同一張表里，避免了跨表查詢。
（2）適當的數據冗余。 如果你需要顯示評論人的相關信息，那么在插入評論時就把這些信息寫入評論表中，避免多次查詢。 實際上，如果是紀錄數據，都可以冗余對應的數據信息，因為它們的數據的實時行和一致性要求並不高。
（3）附加冪。數據只允許單項操作。 因為從冪性的要求來說，每個贊全都是一條記錄。 評論的贊數如果都從點贊表中統計得出，那么性能開銷會十分巨大，而且點贊如此輕量級的一個操作一定會加劇點贊表的競爭操作。 所以建議直接在評論表中添加一個like_count的計數器，該字段只增不減。客戶端，可以設置取消效果。
（4）熱門評論加緩存。 類似於網易新聞的熱門評論，讀取頻度非常高，可以專門開接口做緩存。