关于类似网易评论盖楼的数据库设计 或者 reddit 那种方式，对评论进行评论 表应该怎么设计？
我的想法是一次性把某主题下所有的评论全部读取处理，做完处理再显示 但要是评论很多，一次性全部取出来耗资源，大家有没有更优化的设计想法？
如果是关系型数据库可以试试 nested set model http://en.wikipedia.org/wiki/Nested_set_model gem: https://github.com/collectiveidea/awesome_nested_set
Trees in MongoDB http://www.mongodb.org/display/DOCS/Trees+in+MongoDB
不单是说 mongodb，还说了其他设计思路
有好几种设计模型，各有优点，需要兼顾增删改查不同操作的效率。提供几个关键词供搜索 tree threaded hierarchical。
另：
- reddit 貌似是开源的（记得至少以前的 webpy 版是开源的），可以看看代码，不过是 python 的。
- 推荐一种方案，基于 PATH 的。使用一个叫 ancestry 的 gem https://github.com/stefankroes/ancestry 。视频 http://railscasts.com/episodes/262-trees-with-ancestry 。如果深度不那么深，推荐一下。每次增删改，只影响一条记录。Postgres 有 ltree 模块，与这个设计思路应该是一样的。
- MongoDB 可以直接保存嵌套数据。但不能查找某一个评论。
楼主研究透了，可以分享一下哈~
stackoverflow 上的一个总结（好棒的社区哇） ，不知道复制过来是否合适⋯⋯
What are the Options for Storing Hierarchical Data in a Relational Database?
#2 楼 @caryl nested set 不适合 comments 这种场景，插入代价太高了，每次插入要更新整个表。这种插入多的树结构建议用 ancestry ，不同于 nested set，ancestry 把 ancestors 以 path 的形式保存，比如 comment 3 回复的 comment 2，comment 2 又回复的 comment 1, comment 3 的 ancestry 就是 1/2。ancestry 的大部分查询都只用一次 SQL，虽然 desendents 要用到 LIKE，但是不是以通配符开头，所以可以利用到 index。唯一限制的是 ancestry 最长是 255 个字符
有一个 mongoid-tree, 实现方式楼主可以参考一下 它是用两组外键 一个 parent_id 外加一个 parent_ids，后者用来查询间接先祖和子孙节点 , 配合上 identity map，使用起来效果还行
