Hibernate论坛 "板块"与 "帖子" 之间要不要配置成1对多

板块下 有 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,根本不用担心,业务场景决定你的做法。

评论?火星那样弄就不错的。。。。分开也行,也是看你的业务场景罗。。

先考虑需要什么?有没有必要?

复杂问题简单化,不要一开始什么都想得很完美,撑不住。。