这样的需求该不该用一对多设计，主要考虑性能

但这样好像不方便检索 。

  good idea!



还希望大家再讨论一下  1：n 中 儿子特别多 时候 还要有分页可能时， 是否还有必要配成 1:n

比如 论坛栏目 和 栏目下的主题

1个栏目下有 10000个主题， 如果配成 1:n主要从3个页面角度考虑，


1 : 显示所有栏目

2 ：显示某个栏目下的主题 （带分页）

3： 删除某个栏目，（当然栏目没了，主题也不应该在存在于数据库中)


最后 ：问 该不该配成 1: n  ( 当然lazy=true)

主题是论坛的资源，和属于什么板块没有关系。不管你板块则么合并拆分主题总归要留着俄，你可以写一下匹配规则把符合的主题和新的板块建立关联。

相信你这么说是对的。 


我是说如果按我的要求，来设计的话。 我就想搞明白 1：n  这种情况  是取还是舍。至于实际意义倒是其次。

如果是我来做的话，不会用hibernate来维持关系。

恩，是的。

没关系把。直接lazy=true就可以吧/。select* from一般对索引查询。跟表的大小没关系的吧

有一种可能是网站规模不是那么大, 现在内存很便宜, 假如所有数据在物理内存都放得下的话, 全部配成级联, 分页直接用集合方式做, 不查数据库, 会是一个运行效率最高, 开发成本最低的方案.

假设每条帖子平均占2K内存, 那么20G内存可以容纳一千万帖子, 在这个范围之内, 64G内存的服务器跑起来应该没有问题.

:x 规模大的不会用这个，规模小的也出不起这个钱。

对于topic跟content这种情况当然应该设成多对一，因为实际使用时总是通过topic来顺藤摸瓜取得content的，如果设成一对多，取得的content是个集合，反而增加了麻烦。
还有一个好处就是不需要额外查询数据库，通过topic本身就能知道content是否存在。
如果非要用一对一可以将content设为主，topic为从，也可实现content的lazy，如果反过来设置则前功尽弃适得其反。

对于一对多中多方很多的话，如果是我不会用，而只用多对一关联，毕竟将多方全部显示的情况不多，一般都会进行一些条件查询。