板块下 有 1万个帖子 ， 某个帖子下 有 500条评论
这种情况下 把 "板块"与 "帖子" 之间， "帖子" 与 "评论" 之间 配置成1对多 好么 ？
----------------------------------
我知道有个 “懒加载” 但总担心 当 需要显示 板块下有 多少 帖子时候 ，执行 耗时的查询 。
配成 1对 多 一个 好处就是 级联删除方便。
不知道大家 怎么处理这种 儿孙 特别多的 情况 ？
"板块"与 "帖子"配置成一对多是没有问题的，但是把关系维护在"帖子"上，也即"板块"感觉不到"帖子"的存在，只有点击了“板块”之后，再去“帖子”里查找属于这个板块的帖子。
"帖子" 与 "评论" 之间也是一对多，但是这个我觉得"评论"就相当于回帖，所以"帖子" 和 "评论" 可以设计成同一个domain，就是里面多了一个parent属性指向自己。也就是这样：
[code="java"]
public class Topic {
private String id;
private String title;
private String content;
@ManyToOne
private Topic parent;
}
[/code]
坚决不能配置成关联关系映射，数据量也大越不能这么干，虽然缓存能起到一定作用，但那玩意儿吃内存啊
数据量这么大，还是别用级联了。不能为了程序写起来方便就去损失性能。
多写几条hql也不费事，效率也高些
不级联就省内存吗？你可以看看雷傲、动网之类的论坛的数据库，我记得不错的话，它们都用了关联。如何使用，要看你的业务场景。
大数据量关联查询有时候是性能比较低，延迟加载可以解决这个问题，因为帖子不会在一页同时显示，通常都是分页的，这样内存的占用就小很多了。另外，oracle之类的数据库也提供了优化措施，比如hash link。
如果需要“回复的回复”，就像火星说的，可以和帖子放在一个表里面。不过这和多对一没有什么区别。
一个板块有多少帖子，你可以观察一下流行的论坛，都没有准确的“帖子数”，通常只是提供分页，而不提供总的数量，因为论坛这个业务场景没有必要显示总共多少帖子。如果一定要显示，海量count查询通常比较慢，可以让它走索引以提高10倍左右的速度，但仍然慢。用异步的方式也许是好的方案。
非常大的数据量，比如google论坛，都是采用异步+静态化的方式，所以每次在google发帖子的时候总是提示“你的帖子不久就可以看到了”。
我见过的论坛，貌似都关联上了。消耗内存？貌似有lazy loading，根本不用担心，业务场景决定你的做法。
评论？火星那样弄就不错的。。。。分开也行，也是看你的业务场景罗。。
先考虑需要什么？有没有必要？
复杂问题简单化，不要一开始什么都想得很完美，撑不住。。