類似於評論嵌套回複的資料庫怎麼設計？

第一種情形

評論嵌套回複，類似於這種情況，資料庫是怎麼設計的？

我有兩種思路，一種是存一下回複的評論id，這樣不好出就是每個嵌套評論都要迭代出所有的父類，效能不好。第二種思路是存一下所有父類的id，用一種符號(逗號或者破折號)分開，存在一個欄位中。

第二種情形

微博轉寄，資料庫是怎麼設計的？
同樣我也有兩種思路，一種是存轉寄的人內容id，一種是存曾經轉寄這條微博的所有人的id，另一種存轉寄的所有內容。用哪一種更為合適？

還有沒有更合適的思路呢。？請大家不吝指出。

回複內容：

第一種情形

評論嵌套回複，類似於這種情況，資料庫是怎麼設計的？

我有兩種思路，一種是存一下回複的評論id，這樣不好出就是每個嵌套評論都要迭代出所有的父類，效能不好。第二種思路是存一下所有父類的id，用一種符號(逗號或者破折號)分開，存在一個欄位中。

第二種情形

微博轉寄，資料庫是怎麼設計的？
同樣我也有兩種思路，一種是存轉寄的人內容id，一種是存曾經轉寄這條微博的所有人的id，另一種存轉寄的所有內容。用哪一種更為合適？

還有沒有更合適的思路呢。？請大家不吝指出。

針對評論蓋樓

首先，現在這種形式不多見了，功能上簡化了，不適用與移動產品的潮流。
就實現上，以前我們是 每條資料記錄了他回複的評論編號。看了你的問題，個人感覺，你的第二種實現採用冗餘儲存，記錄所有的上級的評論編號，是個不錯的注意，效能更好一些。在儲存多值時，以前喜歡用逗號隔開，現在喜歡用json_encode儲存。使用和儲存更靈活一些。

針對微博轉寄

個人想法是，有個關係表，每次轉寄為一條關係資料，因為轉寄不存在蓋樓的問題。

參考論壇的資料結構設計吧

