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

一个论坛网站用mysql数据库 ：

有栏目(forum)--〉主题(topic)---〉回复(topic_back)  三个表,其中 topic表里面有 content字段是 text类型。

现在我困惑的是 ：

要不要让栏目和主题配成 1:n 关系，要不要把 主题和回复配成 1:n 关系

因为一个栏目下面会有很多主题，显示的时候还要用分页。
一个主题下也会有很多回复，也会用到分页。

虽然 配成1:n后可以采用 lazy=true 这样在 得到栏目时，并不立即读出该栏目下的所有主题，但是我将来分页该怎么做呢？难道利用  循环 栏目下面 表示主题的集合 ？ 另外也担心只列出所有栏目时，因为配置了栏目和主题的1:n而降低执行速度。

若不配成 1:n那删除栏目时，栏目下的主题就没法被级联删除，必须手工删除，这样提高了开发成本。


我本人是倾向于配成 1:n关系的，不知道大家遇到一个父亲下面有大量儿子（甚至还分页）时，是不是仍然肯培成1:n关系？ 希望听听大家的理由，谢谢。


另外 因为topic表里面有text大字段，比如在显示某个栏目下主题列表这个界面，只显示出主题的标题等，并不显示内容这个大字段，如果我在这里取出的是主题这个PO，那对应的SQL语句必定是 select * from topic 的，我理解读取text大字段，无论在查询和传输上都是比较耗时的。

因此我想到两种解决办法：

1：放弃读取PO ,而变成读取PO 中用到的字段对应的属性，但这样就不OO 了，估计也放弃了一些hibernate的缓存方面的优化。

2：我把content等不常用的字段 挪到另外的一个表中比如叫 topic_content表，然后再映射一个hibernate 实体， 最后 topic和topic_content组成 1：1关联。但 1:1关联中没有 lazy属性，也不知道这样能不能做到不需要读content大字段时就不去数据库读，来达到优化的目的。

谢谢。

我会选择方案2。避免了text的问题。

把栏目想象成lable比较好，栏目删除的时候主题不需要删除。

方案2，topic跟content可以映射为多对一的关系。这样就可以设置lazy了。

我会选择这个方案，这并没有什么不oo之说，oo不oo主要看你的模型设计，这样做是可以利用hibernate的缓存的，没有问题。

这个我到觉得非常不oo，数据库设计也不合理，平白无故的就都出来一个对象，一个表，显然不是很合理，权衡一下，方案一是最合适的。

原先的设计才是不合理，topic存一个标题就够了，发帖的内容和回复都应该在另一张表里面存储。

可以考虑把正文存在文件系统，在需要显示content的页面上用ajax直接请求该文本文件并显示

你说得对，之前我没有仔细看，其实发贴得内容和回复得性质是一样得，楼主原先得设计确实不合理，但是楼主后来得方案2确实还是不合理，呵呵，比较合理得做法是表得设计采用dada得方案

其实这只是举个例子来说明 1：n 的问题， 但 如你所说，栏目删除了，那里面的主题将不会再有链接可以被访问到，还留着有什么用呢？

这个办法挺好，不过是不是说反了， topic和topic_content应该配成 1：n 而不是 n:1吧。