我有一个矛盾，我前段时间花了好多时间研究jive，觉得它的模式很好，连我自己写的论坛也很多部分参照了它。但是前两个月我到一家公司任职后，却发现jive在对数据库处理上其实做得并不那么好。
例如，jive在读取论坛帖子时，通常使用一次历遍，将所有的ID取出，然后在读取每个帖子的属性，这样如果有n条数据，就运行n+1次sql。但是为什么它不直接运行一次sql直接把帖子的所有属性（包括ID）等读取出来？在公司，我写一些程序的时候，本来也使用这种方式的，但是后来却发现这样其实对数据库的负担也实在很大，所以最后我还是选择了运行一次sql，把属性都读取到一个数组里。
在jive中对数据库开销的例子还很多，例如，我们编辑帖子，它有好多的方法，setTitile(title)，setContent(content),每set一个属性，它就运行一次update的sql，但是为什么不先把所有的属性都set好，然后一次update进数据库呢？
是我的想法错吗？大家还有没有什么好的办法？
jive的模式对数据库的损耗可能比较大，但这种模式可以节约 AppServer的系统资源。
“先遍历ID，然后再Iterator分次读取属性”- 这种方式比较适合海量数据的遍历与“分页显示”---
而一次性将所有符合条件的数据装入自己的数据结构---这种方式比较适合小数据量的遍历。
各有各的优势，分清不同应用场景而选用相应的解决方案。
：：个人观点：：
始终认为是理论性的东西，与真实实践有很大差距。
>jive在读取论坛帖子时，通常使用一次历遍，将所有的ID取出，然后在读>取每个帖子的属性，这样如果有n条数据，就运行n+1次sql。
因为前面有缓存拦截，所以不存在n+1次sql，你一次性将所有数据读出来才是耗费数据库的做法呢。
Cache不能解决所有问题-[对于对实时性要求很高的应用，就要考虑Cache的合理使用了]
不能否认，只有使用了Iterator才能有效地利用Cache-
如果是小数据量：
1、获取记录：
获取ResultSet，一次性导入然后遍历---不失为一种便捷的方法[rs.next();时，你只是作了一个标记，rs.getXxx();时才从数据库中读取数据的]
2、更新记录：
使用JDBC事务控制与executeBatch();操作数据库，不仅使用方便，并且速度较快。
::Personal ViewPoint
想请教，可能我的观点有错，请指出。
我的观点是这样的：
即使有jive中有缓存机制，但是第一次也需要从数据库中读去出来阿。这不是需要n+1次sql吗？
可能自己经验不足吧。但是在我实际应用中，我曾试过使用jive这种方式读取方法做一些列表操作，运行时间的确比只运行一条sql的要慢。
的确,cache不能解决所有的问题!
对更新要求很高的需求根本无法满足.
个人观点.
jive的确对数据库的开销比较大.
对实时性能要求不高的才用cache没问题
象论坛之类的
另外一些就不能采用
需要实时刷新
例如银行等和金融相关的
做不同的项目，
有不同需求。
得有区分的对待
不能一概而论
Cache不能解决所有的问题，一方面在大规模完全随机的访问情况下，Cache不起什么作用，如果加大Cache则也是一种系统消耗，另外Cache在分布式运行时很难进行同步处理，即使用JGroup，也要考虑网络传输带来的消耗。
我觉得对于分页方法，还是针对不同的数据库做不同的处理，比如Mysql用limit，Oracle用rownum，SQL Server用TOP等等，在我做的社区中，已经可以对分页类进行封装已达到数据库通用的目的，同时提高了数据库的查寻效率，我最近在用Hibernate做社区新版本，Hibernate在处理数据库分页的方法上和我的思路基本是一样的，都是根据不同的数据库生成不同的SQL。
还有一个原则，JAVA程序的结构和性能是一个对立面，想要用良好的机构就要牺牲性能。