这一节里,使用了一个实际的例子来说明dynamic-mapped-statement 和 insert 的简单使用.
系统发布后一段时间,对系统留下的一些log,特别是所执行的sql语句进行分析,来获取用户使用习惯的第一手数据,以便以后我们的改进。
今天就做了这样一次简单的分析,由于系统中几乎所有的查询都使用我的一个统一的借口来进行查询,所以sql的log有统一的标志,收集起来相对容易。
下面一步一步的描述一下整个过程:
一、搜集log
1. 从服务器上获取log文件,无需多说
2. 用程序分析log,并将sql解析出来,做一些处理,保存到数据库中。
要保存一条数据到数据库里,需要配置一个保存的sql:
<parameter-map name="insert-params"> <property name="exetime" /> <property name="sql"/> <property name="parsedsql"/> <property name="sqlvalues"/> </parameter-map> <mapped-statement name="insertsql" parameter-map="insert-params" > insert into sql_stmt ( id, exe_time, sql, parsed_sql, sql_values) values ( <!--注意这里,可以使用数据库本身的功能,不受限制--> seq_sql_stmt.nextval, ?, ?, ?,? ) </mapped-statement> |
程序里只需要提供一个简单的bean,这个bean只需要带有"insert-params"配置的那几个field就可以了,在程序里我们只需要:
sqllog log = parsesqllog(sqlstring);//set 相关字段 sqlmapconfig.getsqlmap().executeupdate("insertsql", log); |
这样就保存好了,简单吧。
3. 用程序跑,把所有log分析完,都写到数据库里去
三、分析log
也许保存数据上,看不出多少和其他orm工具的差别,甚至还会觉得更麻烦一点,下面用一个查询的例子来说明ibatis的灵活与强大。
为了分析这些log,我在往数据库里写的时候,把sql里的值都去掉了,替换成prepared类似的sql,以便于分析sql的普遍性。在这里提一句题外话,在设计dao框架的时候,最好考虑以后可能的扩展,使用比较好的框架是很重要的,就象这里搜集log,由于我们使用了统一的接口,不仅log搜集容易,对于以后的扩展与修改也很重要,比如现在我就在修改我们的一个util,让所有的sql都用绑定的方式执行,如果没有以前好的设计,现在要修改几乎是不可能的!
log分析出来大概有80多万记录,我们需要从中获取一些有用的信息,就必须提供一个简单的查询。经过简单的了解后,我们大致需要几个条件:执行时间,sql语句(模糊查询),统计的条数。
于是,就开始写配置文件:
[code]
<dynamic-mapped-statement name="getsqllogstatistics" cache-model="sqllog-cache"
result-map="sqllog-hashmap-result" >
select * from (select rownum count_row_num, w_o_l_f_w.* from (
select * from (
select parsed_sql,count(*) cnt from sql_stmt
<dynamic prepend="where">
<isnotnull prepend="and" property="exetimestart">
<![cdata[exe_time >= #exetimestart#]]>
</isnotnull>
<isnotnull prepend="and" property="exetimeend">
<![cdata[ exe_time <= #exetimeend# ]]>
</isnotnull>
<isnotempty prepend="and" property="sql">
(sql like '%'||#sql#||'%' or parsed_sql like '%'||#sql#||'%' )
</isnotempty>
</dynamic>
<dynamic prepend="having">
<isnotempty property="countfrom">
<![cdata[ count(*) >= #countfrom# ]]>
</isnotempty>
<isnotempty prepend="and" property="countto">
<![cdata[ count(*) <= #countto# ]]>
</isnotempty>
</dynamic>
group by parsed_sql
<![cdata[
) order by cnt desc ) w_o_l_f_w
where rownum < #__endpoint#)
where (count_row_num >= #__startpoint#)
]]>
</dynamic-mapped-statement>
[/code]
以上的就是一个动态的sql,看起来可能比较难看,但是他管用。
这样,程序里就简单了,在action里,我们把提交的数据简单的处理一下:
[code]
parameterparser pp = data.getparameters();
map params = new hashmap(pp.getkeys().length-2);
object[] keys = pp.getkeys();
for(int i=0;i<keys.length;i++){
string key = (string) keys[i];
if(!"template".equals(key) && !"action".equals(key)){
date tmp = templateutil.getdatefrompicker(pp,key);
if(tmp!=null){
params.put(key,tmp);
}else{
params.put(key,pp.getstring(key).trim());
}
}
}
[/code]
这段代码简单的处理了提交的数据,把他从parameters里拿出来放到一个map里,
做为我们查询的条件,在我们的bean里,只需要:
return sqlmapconfig.getsqlmap().executequeryforlist( "getsqllogstatistics", params); |
很简单吧?
其实,就开发上来说,我们只是把一些以前要在java程序里写的逻辑,比如某个字段是不是有值啊什么的放到了sqlmap的xml里去,工作量并没有减少多少,但是,修改和调整的时候,工作量就大大的减少了,我们不需要去修改程序,编译,发布,再运行,我们只需要简单的修改sqlmap的的xml就可以做到这一点,对于项目后期的调整(比如dba要将sql进行tuning),项目发布后的维护等等,可以说是大大的减轻了工作量。
四、后记
这只是一个非常简单应用,简单的使用了ibatis 的 sqlmap功能,我想我们以后可以考虑在项目中使用它,但是任何一个工具都有他最适用的地方,我的意见是以后的添加修改和删除还是可以继续使用一些orm工具,至于查询么,单表或者简单的有规律的查询可以使用代码生成工具中生出来,对于十分复杂,而且用户又可能经常修改或者说很有可能需要在后期进行性能调整的查询,我们可以考虑使用ibatis.
闽公网安备 35060202000074号