昨天晚上和网友讨论了一个关于数据库联合查询的效率的问题.说实话,以前我一直没怎么考虑过这个问题,在写SQL时,都没怎么考虑,似乎一切都成了习惯,或者已经懒散贯了,但是,网友和我聊起来了,我也就好好考虑起这个问题了,平时不考虑时不知道,真正好好计较一下,才发现还有很多门道.

.................

根据以上的思考,结果很吓人,经过对比,发现,结果好恐怖,遍历次数差别简直就是.........比比看看:600万--2.3万--1600--800,这种比例实在太恐怖了,我不得不对联合查询产生了动摇,难道我们为联合查询的便利,就付出如此巨大的浪费吗?我们真的应该重新审视一下,我们平时已经习惯的编程习惯,以及那些我们认为理所当然的代码............

今天在做项目时,突然发现一个同事在使用Velocity时,写了一些以前我没见过的代码,很是好奇,经过打听,才知道,那些特别的代码原来不是Velocity的标签或者功能,原来是Struts的标签.具体情况是这样的:我们目前项目的开发,使用的是Spring2.5+Struts2+Ibatis2+Velocity,在做一个表单时,我原先写的Velocity代码如下:  .......

当时看到这段代码时,我很是惊喜,代码量减少了大半,我开始以为是Velocity的更高级用法,但是,经过仔细的思索,后,觉得这不是Velocity的语法,而像另一种标签的语法,Struts2的标签.经过一问,果然和我的猜想一样..............

准备学习使用maven，以前对Maven有过了解，不过，看到了一些批评的文章，最后放弃了学习。最近的项目里，公司用到了Maven，在工作中，终于感受到了Maven的魅力了，我觉得，使用Maven的好处大于坏处，在项目中，使用Maven来开发是正确的。但是，目前，还只是简单的了解和使用了一点点，对Maven还是不太懂，但是，现在有兴趣来了，应该好好学习一下，尝试得去用。Maven给我的感觉，最大的作用在于。。。。。。

自从[关于qwikioffice EXT2 desktop转JSP的发展方向] 文章发表以来，众多朋友加入到这个队伍来，而我之前太忙，使得进度缓慢，让大家有所失望。春节回来后，在女友的鼓励下，连续几天高强度的研究qwikioffice的PHP代码，终于使得此工作有了突破进的进展。但是，由于开始设计的思路上不太完善，目前虽然已经基本实现了在JSP平台上的使用，但是，在将来的扩展及使用上，很可能会带来意外的麻烦。

。。。。。。。。。。。。。。。

关于新项目的构思上，目前，我有两种想法：。。。。。。。。。。。。

        作为开发者来说，我很想采用第二种方式，以摆脱被那PHP代码及可怕的表结构设计的烦恼，但是，又担心自主开发时带来与pHP版的差异及升级性问题。目前，我想，还是两个想法同步进行，这样就可以在同时进行两个项目中，相互借鉴，说不定，将来两种方式都成功了，又让世人多一种选择。

        如果新考虑的这两种思路开始了的话，我会第一时间公布项目的SVN地址，希望有想法的朋友们也和我一起来。。。。。。。。。。。。。。。。。