类似于评论嵌套回复的数据库怎么设计？

Question

第一种情形

评论嵌套回复，类似于下图这种情况，数据库是怎么设计的？

我有两种思路，一种是存一下回复的评论id，这样不好出就是每个嵌套评论都要迭代出所有的父类，性能不好。第二种思路是存一下所有父类的id，用一种符号(逗号或者破折号)分开，存在一个字段中。

第二种情形

微博转发，数据库是怎么设计的？
同样我也有两种思路，一种是存转发的人内容id，一种是存曾经转发这条微博的所有人的id，另一种存转发的所有内容。用哪一种更为合适？

还有没有更合适的思路呢。？请大家不吝指出。

Answer 1

针对评论盖楼

首先，现在这种形式不多见了，功能上简化了，不适用与移动产品的潮流。
就实现上，以前我们是 每条数据记录了他回复的评论编号。看了你的问题，个人感觉，你的第二种实现采用冗余存储，记录所有的上级的评论编号，是个不错的注意，性能更好一些。在存储多值时，以前喜欢用逗号隔开，现在喜欢用json_encode存储。使用和存储更灵活一些。

针对微博转发

个人想法是，有个关系表，每次转发为一条关系数据，因为转发不存在盖楼的问题。

Answer 2

都过去三年了啊 --！ 先说一下我之前做的一个项目 也是 评论 回复 回复这种 ，我用的是一张表 存储所有评论及回复 字段只有create_time，id user_id 文章id 评论内容 parent_id 估计你看到这也明白了 用的自关联，这样查询应该更快。

Answer 3

参考论坛的数据结构设计吧