这样的需求其实挺特殊，每个“楼”都是一个独立的“树”，每个“楼”都“几乎”不用依赖其他的“楼”。
最简单、最高效的方式是用文件来存储每一个楼，每个新闻一个楼，使用xml、json等树形结构的文件格式来规范评论和新闻内容。这样每进一个楼只需要访问一个文件，发评论只是创建一个文件，把楼盖高，只是给增加新内容。而新闻列表可以存储在数据库中，也可以用lucene做索引。

如果一定要用数据库实现，那么新闻（主贴）做一张表，评论（回贴）做一张表，评论表中添加新闻id字段作为与新闻表的外键关联即可。如果要进一步完善树形结构，评论表上补充一个指回评论表的外键即可。

如果性能非常重要，这个方式是很有意义的，而且新闻列表一定是用lucene做索引。
新闻首页一定不是直接查询数据库，而是静态化该页面。在后台做一个轮训器，定期更新这个静态页，如果有重大新闻发生，强制更新该页面。
新闻内容、评价页静态化或者单文件处理，能极大降低服务器压力，毕竟没有数据库操作。每天一个目录，或者每小时一个目录，在文件存储方面就不会对文件系统形成较大压力。

2、
于数据压力，用数据库的话，可以分拆为每年、每个月再或者每周一个新闻库，只需要每次新增一个库即可。具体的处理方式就要看你用的数据库。
某些情况下，将当月、重点的新闻单独提炼出来静态页面项目，需要对当月、重点的新闻做大规模的负载均衡，对其他不重要新闻则使用普通的方式。

新闻内容如果静态化
优势：可以使用apache甚至lighttpd、nginx服务器，对应的处理压力的能力较强。
方式：可以用新闻内容本身+新闻模版生成静态的新闻文件，在新闻文件上用ajax异步加载新闻的评论。
缺点：新闻页面上的其他因素成为开发起来比较麻烦的东西，比如广告、相关文章链

新闻内容如果不静态化
缺点：使用的服务器受到你的系统的架构的影响，处理压力的能力受限。
方式：可以将该新闻的内容、评论等相关因素放在一个xml里面，访问该新闻时仅仅读一个新闻xml，仅一次读IO，性能上不会有较大压力。前端可以再加一个集中式缓存(比如memcached),将读的次数非常多的新闻存在缓存中，进一步减少IO数。
有点：灵活。

“评论盖楼”的设计思路