我认为jive对数据库的开销是比较大的,在实际项目中我认为不易推广这方式,你认为呢?

04-09-04 kafeleung
我有一个矛盾,我前段时间花了好多时间研究jive,觉得它的模式很好,连我自己写的论坛也很多部分参照了它。但是前两个月我到一家公司任职后,却发现jive在对数据库处理上其实做得并不那么好。

例如,jive在读取论坛帖子时,通常使用一次历遍,将所有的ID取出,然后在读取每个帖子的属性,这样如果有n条数据,就运行n+1次sql。但是为什么它不直接运行一次sql直接把帖子的所有属性(包括ID)等读取出来?在公司,我写一些程序的时候,本来也使用这种方式的,但是后来却发现这样其实对数据库的负担也实在很大,所以最后我还是选择了运行一次sql,把属性都读取到一个数组里。

在jive中对数据库开销的例子还很多,例如,我们编辑帖子,它有好多的方法,setTitile(title),setContent(content),每set一个属性,它就运行一次update的sql,但是为什么不先把所有的属性都set好,然后一次update进数据库呢?

是我的想法错吗?大家还有没有什么好的办法?

Juniper
2004-09-04 15:13
jive的模式对数据库的损耗可能比较大,但这种模式可以节约 AppServer的系统资源。

“先遍历ID,然后再Iterator分次读取属性”- 这种方式比较适合海量数据的遍历与“分页显示”---

而一次性将所有符合条件的数据装入自己的数据结构---这种方式比较适合小数据量的遍历。

各有各的优势,分清不同应用场景而选用相应的解决方案。

::个人观点::

anonymous
2004-09-04 16:12
始终认为是理论性的东西,与真实实践有很大差距。

banq
2004-09-04 16:55
>jive在读取论坛帖子时,通常使用一次历遍,将所有的ID取出,然后在读>取每个帖子的属性,这样如果有n条数据,就运行n+1次sql。

因为前面有缓存拦截,所以不存在n+1次sql,你一次性将所有数据读出来才是耗费数据库的做法呢。

Juniper
2004-09-04 17:17
Cache不能解决所有问题-[对于对实时性要求很高的应用,就要考虑Cache的合理使用了]

不能否认,只有使用了Iterator才能有效地利用Cache-

如果是小数据量:

1、获取记录:

获取ResultSet,一次性导入然后遍历---不失为一种便捷的方法[rs.next();时,你只是作了一个标记,rs.getXxx();时才从数据库中读取数据的]

2、更新记录:

使用JDBC事务控制与executeBatch();操作数据库,不仅使用方便,并且速度较快。

::Personal ViewPoint

kafeleung
2004-09-04 18:24
想请教,可能我的观点有错,请指出。

我的观点是这样的:

即使有jive中有缓存机制,但是第一次也需要从数据库中读去出来阿。这不是需要n+1次sql吗?

kafeleung
2004-09-04 18:42
可能自己经验不足吧。但是在我实际应用中,我曾试过使用jive这种方式读取方法做一些列表操作,运行时间的确比只运行一条sql的要慢。

ynk
2004-09-05 00:20
的确,cache不能解决所有的问题!

对更新要求很高的需求根本无法满足.

个人观点.

jive的确对数据库的开销比较大.

SportsBaby1980
2004-09-07 10:12
对实时性能要求不高的才用cache没问题

象论坛之类的

另外一些就不能采用

需要实时刷新

例如银行等和金融相关的

做不同的项目,

有不同需求。

得有区分的对待

不能一概而论

laoer
2004-09-08 16:09
Cache不能解决所有的问题,一方面在大规模完全随机的访问情况下,Cache不起什么作用,如果加大Cache则也是一种系统消耗,另外Cache在分布式运行时很难进行同步处理,即使用JGroup,也要考虑网络传输带来的消耗。

我觉得对于分页方法,还是针对不同的数据库做不同的处理,比如Mysql用limit,Oracle用rownum,SQL Server用TOP等等,在我做的社区中,已经可以对分页类进行封装已达到数据库通用的目的,同时提高了数据库的查寻效率,我最近在用Hibernate做社区新版本,Hibernate在处理数据库分页的方法上和我的思路基本是一样的,都是根据不同的数据库生成不同的SQL。

还有一个原则,JAVA程序的结构和性能是一个对立面,想要用良好的机构就要牺牲性能。

猜你喜欢