談談我對評論系統有限層及無限層評論的膚淺認知

由於本人並未開發過評論系統，也不是很瞭解其中原理，此文僅作為個人認知，誠懇接受大家的批評指正。

本文提到的有限層評論其實僅限於單層或者雙層。

一、單層評論的優缺點及中庸之道
優點：儲存結構簡單，無需多餘的表連線，提取資料快。
缺點：多數情況下無法看出當前評論是針對哪個評論而發出的評論，也就是說無法看出當前評論的父節點。

比如本社群的文章某個評論的下面，繼這個評論的所有評論都是平行結構。雖然社群有評論提示功能，但是新增回復都是在首個評論的下面，如果我點了這個“新增回復”，到底是最後一個評論者收到這個提示，還是首個評論者收到提示，還是有所此條評論及其下所有評論者都收到提示呢？不是很清楚。

中庸之道：
1、加入引用（quote）形成表現層的層次結構，但是在儲存上存在2種方式：
1.1、引用評論的ID；
1.2、直接引用內容。
前者的缺點是如果允許使用者修改或者刪除評論，那麼可能出現下面的評論內容很奇怪或者設計不當出現後續內容無法顯示等問題，當然引用ID會在根據ID讀取內容上可能存在效能問題，由此可能牽扯出是否後臺設計上已經是一種樹形結構的多層評論系統的設計；
後者的便捷之處就是直接提取內容，如果這種引用層次非常深，可能簡潔及美觀上值得商榷同時需要考慮資料的儲存方式，當然也存在上面提到的前一種情況。
2、使用@提示：這樣雖然不能解決評論層次問題，但是可以明確表明我想針對誰的評論進行評論。當然如果系統支援@提醒，那麼更好了，如果不支援@提醒，那麼還要@有什麼用呢？

---

2、無限層評論的優缺點及中庸之道
此種形式表現上非常形似引用。
優點：結構清晰，系統可以直接針對這種結構有針對性的提醒使用者。
缺點：儲存結構複雜，提取資料時在效率上沒有單層高，將所有的困難都拋給了設計人員：刪除評論的處理、某條評論所有子評論的統計、評論路徑的顯示等等。
中庸之道：
可以根據實際的情況選擇合適的儲存結構：鄰接表？列舉路徑？閉包表？（具體請參閱《SQL反模式》），再者現在多數資料庫都支援公用表表示式（CTE），這是一種使用臨時命名的結果集，可以減少以往使用遊標遞迴鎖表時間，其效率較遊標形式高出許多。
同時無限層也存在這引用評論這種形式的一些弊端。

---

現在主流使用單層、引用、@並存的方式，既可以增加使用者的可選擇性，又可以適度的提高表現的形式，同時還可以提醒使用者。

以上是個人一些膚淺的看法，向各位老師學習。