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

第一种情形

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

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

第二种情形

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

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

回复内容：

第一种情形

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

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

第二种情形

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

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

针对评论盖楼

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

针对微博转发

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

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