锁定老帖子 主题:数据库动态查询最佳实现
该帖已经被评为新手帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-03-27
你现在的写法是'#['开头和']'结尾来匹配
我的意思是用'and'开头和'换行'结尾来匹配(还可以加上or) 二者是等价的。 |
|
返回顶楼 | |
发表时间:2009-03-27
类似这样的做法,论坛上已经讨论过很多回了。这个实在有点标题党的味道。
在若干年前,我们就曾经搞过使用模板技术来动态生成SQL的方案,当时甚至还更进了一步,采取了从头到尾的一揽子方案,因为我们的开发框架基本固定:Webwork2(Struts2) + Spring + Hibernate。 当时这种一揽子的方案,甚至还包括对html中的input等元素进行name的改造: <input type="text" name="eq.user.name"> <input type="text" name="gt.user.birthday"> 然后在Web层搞一个拦截器,来解析特定前缀的name的input,select标签的值,从而动态构造一个类似SearchComponent的东西来动态构造hql或者sql。所以,连所谓的sql模板编写都省了,根本不需要#[]这样的标签,只要提供一个sql模板就可以了。 所谓的框架,都有这样那样的问题,用上了这样的东西,又会嫌这嫌那,所以不要说什么动态查询的最佳实现,只是一个小工具而已。 |
|
返回顶楼 | |
发表时间:2009-03-27
zhongxuchen 写道 现在人真怪异了,难道大家做开发数据库不是用的最多嘛?做系统不就是为了查询统计嘛?查询难道就不涉及到sql或hql嘛?写sql和hql难道你们就习惯用
if(查询条件不为空或什么) queryStr.append()吗? 我真服了,如此常用的好东西没有人关心,数据库部分在开发中占多大比重不清楚?! 就整天胡扯一些飘忽的技术,有人说面向对象根本不需要写sql,hql多表时性能是低劣的,有些功能hql是没有办法做到的,所以简单的可以用hql,复杂的需要用sql,当然不管是sql还是hql动态参数时if() append()是极其丑陋的,sql或hql写在代码中也是极其痛苦的! 我自己做了个东西,感觉比你这个好 |
|
返回顶楼 | |
发表时间:2009-03-27
最后修改:2009-03-27
to QuakeWang and downpour
我想二位都犯了同样的问题:走极端! 一个说用and 和 换行来做标志;一个说从上到下通过模板来实现sql动态! 第一:and和换行这就严重约束了sql语句的写法,必须严格按照你的约定来换行,否则就完蛋。其实你根本就没有考虑一些特殊问题比方 #[t.date>=:begindate and t.date<=:enddate],这个只要有一个为null整体都得拿掉,还有很多类似的问题,你的做法限制过于苛刻,这样用反而成了累赘。 第二:所谓一览子方案,也是属于过头的行为,人家就是为了sql(hql)用起来方便一点,你搞那么一大套把人都给套住了,我相信你们现在也不再这么用了,为什么呢? 我想任何事情都要把握一个度,好东西就是放那提供一个选择,你觉得好就用,不好你依然可以用你以前的方式,等习惯了就觉得好了。 其实我们的调用也可以是 String queryStr="select * from ORGAN_INFO"; List result=this.findByjdbcQuery(queryStr,null,null,OrganInfo.class); 第一个参数可以直接是sql也可以是NamedQuery(只是说明一下,我们的东西并不强制你一定把sql放到xml中)。 其实很多技术人员太过去看重技术(尤其有时后一些公司面试的人,不把别人问趴下就感觉自己没有面子死扣技术,其实更应该看看人的思维能力),我想有时候是idea问题以及尺度的把握问题,我的这种做法,用#[]实现起来容易,而且用户不需要在意换行排版,另外我们的用法并不限制你用什么框架和技术,它放在那边只是你的一个选择! 可能用词不够委婉,还请大家不要在意,说最佳实现确实是搞一个标题,但我认为我的这种实现对于很多人来说是非常有帮组的,也许他们还在if()if()中,有时候微小的进度都是很困难的,所以即使是微小的改进其实也是值得赞赏的! |
|
返回顶楼 | |
发表时间:2009-03-27
kaipingk 写道 zhongxuchen 写道 现在人真怪异了,难道大家做开发数据库不是用的最多嘛?做系统不就是为了查询统计嘛?查询难道就不涉及到sql或hql嘛?写sql和hql难道你们就习惯用
if(查询条件不为空或什么) queryStr.append()吗? 我真服了,如此常用的好东西没有人关心,数据库部分在开发中占多大比重不清楚?! 就整天胡扯一些飘忽的技术,有人说面向对象根本不需要写sql,hql多表时性能是低劣的,有些功能hql是没有办法做到的,所以简单的可以用hql,复杂的需要用sql,当然不管是sql还是hql动态参数时if() append()是极其丑陋的,sql或hql写在代码中也是极其痛苦的! 我自己做了个东西,感觉比你这个好 说说! |
|
返回顶楼 | |
发表时间:2009-03-27
我觉得这个方法很好的启发了我。我最近为了减轻Dao层的开发强度正在打算用类似Hibernate对象化查询的方式封装JPA的EQL。现在看了你的思路,我觉得你这种比我的要好。我打算这两天就做个最基本的出来,然后根据大家的建议改进。
|
|
返回顶楼 | |
发表时间:2009-03-27
动态的 只能拼语句了
|
|
返回顶楼 | |
发表时间:2009-03-27
zhongxuchen 写道 第一:and和换行这就严重约束了sql语句的写法,必须严格按照你的约定来换行,否则就完蛋。其实你根本就没有考虑一些特殊问题比方 #[t.date>=:begindate and t.date<=:enddate],这个只要有一个为null整体都得拿掉,还有很多类似的问题,你的做法限制过于苛刻,这样用反而成了累赘。 你没有明白我说的意思,具体来说: 你这个例子在开头没有and 或者 or,是不正确的查询,完整的应该类似: select * from table_name t where 1 = 1 #[and t.date >= :begindate and t.date <= :enddate] #[or t.status = :status] 按照我建议的更简化约定来写,就需要写成 select * from table_name t where 1 = 1 and t.date >= :begindate and t.date <= :enddate or t.status = :status 这个lib在读到以and和or开头的行,就可以进行是否要动态拼接的判断,和你用#[]来判断是一样的,你说的整体拿掉,原先代码是拿掉#[]之间的,这里是拿掉整行,也是等价的。 而好处是更简化:先在sql客户端进行复杂的组合sql调试,然后复制过来按这个约定进行排版,无需在每行开头加#[,在结尾加]。 缺点有一些,比如有固定参数的,我们得先写在一行,或者加个空格: select * from table_name t where 1 = 1 and t.date > '20000101' and t.date >= :begindate and t.date <= :enddate and t.status <> 'delete' 但是正如你所说,能够让95%的代码写起来更轻松,另外5%加一些限制也无所谓,这只是看如何取舍的问题。 |
|
返回顶楼 | |
发表时间:2009-03-27
zhongxuchen 写道 写sql和hql难道你们就习惯用
if(查询条件不为空或什么) queryStr.append()吗? 现在除非很老的软件版本 一般不会出现这样的情况了吧,就算有也会慢慢被重构的 zhongxuchen 写道 所以简单的可以用hql,复杂的需要用sql,当然不管是sql还是hql动态参数时if() append()是极其丑陋的,sql或hql写在代码中也是极其痛苦的! 系统都离不开SQL,这样的拼接实现动态确实是丑陋的,SQL不分离也是丑陋的。没错。 但是我被你的标题给骗了。。。。。 很久没在*.java or *.xml出现任何SQL /HQL 的人漂过,一样能实现动态查询。 |
|
返回顶楼 | |
发表时间:2009-03-27
zhenjia 写道 zhongxuchen 写道 写sql和hql难道你们就习惯用
if(查询条件不为空或什么) queryStr.append()吗? 现在除非很老的软件版本 一般不会出现这样的情况了吧,就算有也会慢慢被重构的 zhongxuchen 写道 所以简单的可以用hql,复杂的需要用sql,当然不管是sql还是hql动态参数时if() append()是极其丑陋的,sql或hql写在代码中也是极其痛苦的! 系统都离不开SQL,这样的拼接实现动态确实是丑陋的,SQL不分离也是丑陋的。没错。 但是我被你的标题给骗了。。。。。 很久没在*.java or *.xml出现任何SQL /HQL 的人漂过,一样能实现动态查询。 我真想知道你们很多人说的更好实现,拿出来给大家分享一下,(我想除了QuakeWang 所说的其实跟我的都属于一个套路且不说他这样实现的困难性和写法的苛刻性,都属于特殊符号分割法),说实话想不来就一个sql还能怎么再提高到什么程度,也许需要再换个角度分析,但请分析一下整体成本、易用性、解耦性! |
|
返回顶楼 | |