現在有一張post表 (結構不能改變)

tid 主題pid

pid 回復id

現在新增了評論嵌套顯示功能，即tid=1

a評論了一條 pid為1

b回復了a的評論 pid為2

c回復了b的評論 pid為3

d回復了a pid為4

顯示為

1樓 pid1

2樓 pid1,pid2

3樓 pid1,pid2,pid3

4樓 pid1,pid4

即每一個對他人的回復都需要引用之前所有的回復。

(形式跟網易新聞的評論一樣)

我目前想到一種結構就是post_conversation pid ,to_pid

這樣 2樓回復就插入 2,1

3樓回復就插入兩條 ? ? 3,1

3,2

4樓回復就插入 ? ? ? ? 4,1

如果有一個99樓的對話 就得插入98條數據

這樣有個好處就是可以很方便取出任意一個pid的評論情況

select topid from post_conversation ?where pid = 'xxx' order by pid ;

但是會造成多的重復數據 ?一個99樓對話得插入1+2+3+。。。+99條

如果這么設計 post_conversation

pid,parent_pid(被回復的pid)

數據量是小了，(每次回復只插入一條)；

但是查詢每一個pid的所有對話，很麻煩(我想到的是遞歸查詢數據庫)；

select parent_pid from post_conversation ?where pid = 'xxx'

select parent_pid from post_conversation ?where pid = 'parent_pid '

...

一直到parent_pid 為0為止，查詢出所有的對話pid

請問大家有沒有好的建議

“引用評論”實現代價比較大,冗余比較多,可以考慮用”回復評論”來替代:

一篇文章對應多條評論,一條評論對應多條回復.

問答社區segmentfault.com和騰訊新聞等用的都是”回復評論”.

就拿segmentfault來說:

提問者(樓主)發了一個問題,這個問題有多個回答(層主),在數據庫是一對多的關系.

每個回答又可以有多個回復,也是一對多的關系.

question(id, ? ? ? ? ? ?user_id,content)

answer ?(id,question_id,user_id,content)

reply ? (id,answer_id, ?user_id,content)

謝邀

曾經我這邊也是用最原始那種遞歸查詢的方法來實現(菜單，評論)無限嵌套。后來在 Laravel-China 社區看到管理員發的一篇文章，文章地址https://laravel-china.org/topics/2124，使用

預排序遍歷樹算法(Nested set model)

實現無限樹狀層級模型(標簽系統，菜單系統，評論系統等)。題主可以參考下。

總結

以上是生活随笔為你收集整理的mysql评论表结构设计_文章评论嵌套显示mysql表结构如何设计（形式如网易新闻评论）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。