數(shù)據(jù)庫設(shè)計實現(xiàn)評論回復(fù)功能

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

1、概述

評論功能已經(jīng)成為APP和網(wǎng)站開發(fā)中的必備功能。本文主要介紹評論功能的數(shù)據(jù)庫設(shè)計。

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

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

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

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

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

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

（6）點贊數(shù)、回復(fù)數(shù)等維度的排行等。

評論的后臺管理： 

（1）刪除； 

（2）推薦； 

（3）精華； 

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

本篇文章主要分析幾種客戶端評論數(shù)據(jù)表的設(shè)計。

2、數(shù)據(jù)表設(shè)計

2.1 一問一答模式

(1)需求分析

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

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

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

（2）數(shù)據(jù)庫設(shè)計 

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

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

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

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

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

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

2.2 評論為主模式

(1)需求分析

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

這里將評論分為評論和回復(fù)，所有評論均掛在評論下面，類似于樹狀結(jié)構(gòu)。

(2)數(shù)據(jù)庫設(shè)計 

在以評論為主的樹形顯示情況下，數(shù)據(jù)庫的設(shè)計十分靈活，可以使用單表，添加一個parent_id字段來指向父評論，需要嵌套查詢。

同時也可以將評論拆分為評論表和回復(fù)表，評論掛在各種主題下面，而回復(fù)掛在評論下面。

評論表設(shè)計如下：

回復(fù)表設(shè)計：

由于我們拆分了評論和回復(fù)，那么評論表就不再需要目標(biāo)用戶字段了，因為評論均是用戶對主題的評論，評論表的設(shè)計更佳簡潔了。

回復(fù)表添加了一個comment_id字段來表示該回復(fù)掛在的根評論id，這樣設(shè)計也是出于性能方面的考慮，我們可以直接通過評論id一次性的找出該評論下的所有回復(fù)，然后通過程序來編排回復(fù)的顯示結(jié)構(gòu)。 通過適當(dāng)?shù)娜哂鄟硖岣咝阅芤彩浅Ｓ玫膬?yōu)化手段之一。

reply_type：表示回復(fù)的類型，因為回復(fù)可以是針對評論的回復(fù)(comment)，也可以是針對回復(fù)的回復(fù)(reply)， 通過這個字段來區(qū)分兩種情景。

reply_id：表示回復(fù)目標(biāo)的id，如果reply_type是comment的話，那么reply_id＝commit_id，如果reply_type是reply的話，這表示這條回復(fù)的父回復(fù)。

2.3 網(wǎng)易新聞蓋樓模式

（1）需求分析

這種場景中評論和回復(fù)是同級顯示的，回復(fù)不在顯示結(jié)構(gòu)上不用掛在一個評論下面。 雙表的設(shè)計在這里就不太合適了，因為涉及到評論和回復(fù)的混排，使用雙表則會導(dǎo)致查詢的邏輯過于復(fù)雜。 所以建議還是采用單表的設(shè)計，不區(qū)分評論和回復(fù)會簡化應(yīng)用層的邏輯。 我們統(tǒng)一都看成評論，而有些評論是可以引用其他評論的。

（2）數(shù)據(jù)庫設(shè)計

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

parent_child表：

comment表保存所有評論內(nèi)容，而parent_children表則記錄評論表中各個評論的父子關(guān)系。

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

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

3、數(shù)據(jù)庫優(yōu)化

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

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

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

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

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

到此，相信大家對“數(shù)據(jù)庫設(shè)計實現(xiàn)評論回復(fù)功能”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！