資訊專欄INFORMATION COLUMN
摘要：無限級回復朋友圈也類似，只是有限制層級為級很多人會感興趣網(wǎng)易那種蓋樓的評論的實現(xiàn)，實際上可以理解為是單個回復的進化版，只是它把所有引用的回復的記錄下來了，在展示的時候進行顯示出來而已。
相信大家在平常的系統(tǒng)開發(fā)中，或多或少會涉及到一些評論系統(tǒng)的設計。小到某些工具自己做一些備注（實際上也可以理解為評論），大到類似淘寶天貓這種，都需要一些評論的支撐。
當然，評論有簡單，也有復雜：
簡單的當然就是只有一層的回復了，不能對回復進行另外的回復，類似現(xiàn)在很多迷你社區(qū)帶的@系統(tǒng)，可以把它看成是只有單層的回復。
稍微更進一步的就是可以對回復進行評論的，類似現(xiàn)在的很多XX頭條就是這樣的
稍微更進一步的是可以對回復進行回復，即類似引用，但只可以是單層的，如朋友圈。再復雜一點就是可以多層級的回復了，網(wǎng)易的蓋樓就是這樣的實現(xiàn)，它們的設計可以類似，只是一個字段存放的內(nèi)容的多好而已。
下面我們就針對上面的幾種評論系統(tǒng)作一下描述，當然，只是個人之見，如有不對，還請指出。
單層回復單層回復就是像很多微型社區(qū)里面的@，這個可以簡單地理解為回復。@只是在保存的時候使用正則進行相關的匹配，給那些被@的用戶發(fā)通知。
| column | type | comment |
|---|---|---|
| id | bigint | 主鍵ID |
| uid | bigint | 用戶ID |
| biz_id | bigint | 業(yè)務ID |
| content | text | 評論內(nèi)容 |
| biz_type | tinyint | 業(yè)務類型 |
| create_time | timestamp | 創(chuàng)建時間 |
| modify_time | timestamp | 修改時間 |
| deleted | tinyint | 是否被刪除 |
表結構大概就如上了，當然，很多東西還是要根據(jù)業(yè)務來增減的，比如回復可以發(fā)圖片，那么把圖片多帶帶出來放在一個字段會容易處理得多。
回復可以評論這是回復的進化版，它可以對回復進行評論，而用戶還可以對評論進行評論，類似現(xiàn)在的一些XX頭條基本上都是這樣的。
| column | type | comment |
|---|---|---|
| id | bigint | 主鍵 |
| uid | bigint | 用戶ID |
| biz_id | bigint | 業(yè)務ID |
| biz_type | tinyint | 業(yè)務類型 |
| content | text | 評論內(nèi)容 |
| create_time | timestamp | 創(chuàng)建時間 |
| modify_time | timestamp | 修改時間 |
| deleted | tinyint | 是否被刪除 |
| comment_id | bigint | 回復ID |
| parent_id | bigint | 父ID |
表結構大概跟上面的基礎版類似，只是增加了一個comment_id，它用于記錄需要評論的回復ID（只有是評論的情況下才有值），而parent_id用于記錄評論的父評論ID，只有當對評論進行評論的時候，這個值才會大于0。
無限級回復（朋友圈也類似，只是有限制層級為1級）很多人會感興趣網(wǎng)易那種蓋樓的評論的實現(xiàn)，實際上可以理解為是單個回復的進化版，只是它把所有引用的回復的ID記錄下來了，在展示的時候進行顯示出來而已。
| column | type | comment |
|---|---|---|
| id | bigint | 主鍵 |
| uid | bigint | 用戶ID |
| biz_id | bigint | 業(yè)務ID |
| biz_type | tinyint | 業(yè)務類型 |
| content | text | 評論內(nèi)容 |
| create_time | timestamp | 創(chuàng)建時間 |
| modify_time | timestamp | 修改時間 |
| deleted | tinyint | 是否被刪除 |
| parent_ids | text | 引用評論ID（按順序） |
這里我們新增的是一個parent_ids列，它用于保存引用的評論ID列表，它的順序按照發(fā)表的評論的時間來排，當我們進行蓋樓評論的時候，會拿到之前評論的ID，查到它的parent_ids，合并生成新的parent_ids，然后就可以生成新的評論了。
設計原因評論ID->parent_ids->合并新的parent_ids>生成新的評論
我們會看到第二種區(qū)分評論和回復的設計比第一種和第三種都麻煩一些，而且在查詢的時候也要進行區(qū)分。而第一種和第三種實際上可以合為一個（如果parent_ids為空，則表示是第一級回復，否則則表示是對回復的引用），但考慮到業(yè)務可以會有一些特殊性，在設計的時候盡量應該區(qū)分會更好處理一些。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11740.html
摘要：真正要做高性能的系統(tǒng)，不僅需要在數(shù)據(jù)結構與算法層面深入，更要從硬件操作系統(tǒng)文件系統(tǒng)底層原理等多個領域做更多的研究例如阿里云自研的系統(tǒng)使用了裸盤技術。 《CDN之我見》共由三個篇章組成，分為原理篇、詳解篇和隕坑篇。本篇章適合那些從未接觸過、或僅了解一些 CDN 專業(yè)術語，想深入了解和感受 CDN 究竟是什么的同學。本次由白金老師繼續(xù)為大家分享《CDN之我見》系列二，主要講解緩存是什么、工...
摘要：真正要做高性能的系統(tǒng)，不僅需要在數(shù)據(jù)結構與算法層面深入，更要從硬件操作系統(tǒng)文件系統(tǒng)底層原理等多個領域做更多的研究例如阿里云自研的系統(tǒng)使用了裸盤技術。 《CDN之我見》共由三個篇章組成，分為原理篇、詳解篇和隕坑篇。本篇章適合那些從未接觸過、或僅了解一些 CDN 專業(yè)術語，想深入了解和感受 CDN 究竟是什么的同學。本次由白金老師繼續(xù)為大家分享《CDN之我見》系列二，主要講解緩存是什么、工...
摘要：系統(tǒng)中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。傳統(tǒng)架構升級困難。新的輕量級協(xié)議容器化的出現(xiàn)。熔斷處理在微服務出現(xiàn)問題時防止出現(xiàn)雪崩效應。 聊完Spring Boot，我們來看看Spring Boot最重要的一方面的應用——Spring Cloud。 Spring Cloud 再聊SpringCloud之前我們先聊聊微服務。 ...
摘要：即使秒殺系統(tǒng)崩潰了，也不會對網(wǎng)站造成影響。動態(tài)生成隨機下單頁面的為了避免用戶直接訪問下單需要將動態(tài)化，用隨機數(shù)作為參數(shù)，只能秒殺開始的時候才生成。架構設計如何控制秒殺商品頁面搶購按鈕的可用禁用。該文件不被緩存的做法隨機數(shù)。 秒殺背景 電商中為了吸引顧客、聚集人氣，經(jīng)常會策劃一些秒殺活動。活動中售賣的商品，要么價格遠低于市場價格，要么比較稀缺（如一些新發(fā)布的商品）。這些商品電商一般都會限...
閱讀 2336·2021-11-24 11:16
閱讀 2022·2021-09-30 09:47
閱讀 1996·2021-09-10 10:51
閱讀 1316·2019-08-30 14:08
閱讀 3133·2019-08-30 13:47
閱讀 1520·2019-08-30 13:02
閱讀 3227·2019-08-29 12:29
閱讀 3178·2019-08-26 17:05
