- 浏览: 289983 次
- 性别:
- 来自: 唐山
最新评论
-
小灯笼:
JBPM5.4实战流程引擎开发网盘地址:https://pan ...
跟我学工作流——jBPM4视频教程(免费) -
Kai_Ge:
学会做人 写道临远大哥,谢谢你的贡献大名鼎鼎的临远!!膜拜中。 ...
Spring Security-3.0.1中文官方文档(翻译版) -
漂泊一剑客:
博主,你自己电脑上有下载,这些信息吗,能否分享一下给我
跟我学工作流——jBPM4视频教程(免费) -
Rookie_Li:
您好,您的教程很有用,请问例子的源码在哪下载?
spring security权限管理手册升级至spring security-3.1.3 -
nullFFF:
马教授 写道现在还用4有点过时了,最新的都已经是5.4了,目前 ...
跟我学工作流——jBPM4视频教程(免费)
选择一门新技术,首先要看这门技术是否能够满足目前应用的需求,我们承认任何事物都不会十分完美的同时,也在不断追求着能够为本身应用带来巨大价值的途径。
简单来说,就是因为我们很懒,所以我们会一直寻找能帮我们减轻工作量的东西。
因此,hibernate才能被社区广泛接受,这些团队选用hibernate到底是因为什么原因呢?
1.hibernate是一个orm框架,可以自动完成object和关系数据库之间的转换,加速开发。
这一点就是hibernate最大的特色,不管以前有没有玩过jdbc,看到了hibernate的hello world演示之后估计没有不赞叹的:“操作数据库怎么可能这么简单,hibernate简直是从火星来的哦。”
2.hibernate可以跨数据库。
这一点其实是实现了orm的后遗症,为了实现一个通用orm,就必须兼容主流的数据库,如果hibernate只能在某一个数据库上跑。那它肯定不会有目前的成就。
结果这一点就变成了很多产品开发的基础,这些产品只需要关注自己的业务,不需要考虑在不同的数据库之间进行迁移了,一切底层都交给hibernate,只做好自己擅长的事情,花最少的时间获得最大的价值。
3.hibernate上面附着了一大堆的扩展,hibernate-validator可以做数据校验,hibernate-search可以玩全文检索,hibernate-shard可以做水平分表。
随着不断的发展,hibernate俨然已经发展出一套产品线了,似乎我们只要选择了hibernate,就很容易获得上面说到得这些额外功能,那么到底是自己从头搞起比较爽呢?还是借助社区的力量比较容易呢?一般人还是会选择站在巨人的肩头的,如果所有人都喜欢自己玩,那开源社区也不会这么火了。
毫不脸红的夸完之后,下面是hibernate的问题:
1.封装严重,不容易理解底层实现,导致出现了问题不容易排查。
这个确实无可奈何,它做的太复杂了,但是纵观orm系列,openjpa之类的jar包大小也是在2m左右,这也就说明orm本身是复杂的,选用orm就意味着要负担它的复杂性,如果不愿意付出学习成本,还是选用更简单的实现比较好。简单实现意味着无法满足上述的优点,正所谓鱼与熊掌不可兼得,大家要在实际选型过程中仔细权衡才行。
2.有些人认为hibernate效率极其低下,无法应付庞大数据量的操作。
众所周知的情况是,系统的瓶颈往往会出现在数据库一端,因为我们可以搞20几台web服务器集群,但是加db server却不是那么容易的,一般都要经过水平分表才能实现这类需求。
而对于这种特种应用,说是用hibernate完成关键环节显然是笑话,咱们也不用多说了,还是采用专用的技术去搞定。
反过来,hibernate是否可以应对一般的应用呢?答案是肯定的,因为hibernate仅仅是在jdbc上进行的封装,只是自动处理了数据类型转换,并对每次操作都实现批量处理,相对一般的程序员来说, hibernate所实现的批量处理显然更高一些,与其让那些对数据库一知半解的人去写sql,反倒不如直接用hibernate还来的方便。
一家之言,万望各位指教
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.
Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.
After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.
At this point, you realize this is just another F**KING ORM.
使用框架,能快速解决某方面的问题,但同时也给别方面造成更大的困难。它可能在这方面灵活了,但在别一方面却显得笨拙。在这方面开发有效率了,但在另一方面却是负担。
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.
Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.
After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.
At this point, you realize this is just another F**KING ORM.
没用过Habernate,只知道最基本的功能就是ORM。不过我个人喜欢用SQL语句来解决执行效率问题,而Habernate是解决开发效率问题,这两者还是有不小差异的。
另外,跨数据库的问题,在金融电信等领域,别说跨数据库,连数据库的版本号及其所在的LINUX主机环境都不敢动,一个小小的配置都可能导致灾难性的后果。所以说Habernate与跨数据库放在一起作为它的优点,这恐怕绝对不是原作者的本意,而是一些软件开发者宣传自己产品卖点的一种策略。实际应用中,大多数是些无关紧要的数据库才要考虑移植。
真正的跨数据库,我看还是多从标准SQL语句方面入手吧。
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.
Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.
After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.
At this point, you realize this is just another F**KING ORM.
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
大的项目别说换数据库,数据库版本都不会动,连着固定配置的主机和固定版本的OS一起打包
如果因为主机退市,带来的OS和主机升级会立项成立项目组专门进行移植和测试
现在系统自己实现了类似规则引擎的东西,问为啥不用jrule或者drools一类的成型的东西,曰,那时还没什么人用java
也找不到这些
企业级的产品,Linux这种背景尚且花了这么长时间,不要说其他的东西,如果用hibernate能降低很大成本的,说明原来成本本就不大
这要看情况了,如果你只是做个旧项目的outsource, 那自然不需要考虑跨数据库。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
大的项目别说换数据库,数据库版本都不会动,连着固定配置的主机和固定版本的OS一起打包
如果因为主机退市,带来的OS和主机升级会立项成立项目组专门进行移植和测试
现在系统自己实现了类似规则引擎的东西,问为啥不用jrule或者drools一类的成型的东西,曰,那时还没什么人用java
也找不到这些
企业级的产品,Linux这种背景尚且花了这么长时间,不要说其他的东西,如果用hibernate能降低很大成本的,说明原来成本本就不大
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
如果基于自己的解决方案平台给客户做项目,多数据库的适应性还是非常非常重要的。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
说我的吗?
利用工具很容易打出每一句执行的时间。
别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。
到plsql有时不准,同时一条语句,同样数据量,在生产环境中有时运行700-30000MS之间不等。差别相当的大。
生产环境会受OS和db的缓存的影响的。
利用工具很容易打出每一句执行的时间。
别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。
到plsql有时不准,同时一条语句,同样数据量,在生产环境中有时运行700-30000MS之间不等。差别相当的大。
plsql不准的话。。。。
loadrunner吧
个人认为loadrunner有点重。
利用工具很容易打出每一句执行的时间。
别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。
到plsql有时不准,同时一条语句,同样数据量,在生产环境中有时运行700-30000MS之间不等。差别相当的大。
严重同意,这玩意简直是抢DBA的饭碗。
用了hibernate,大部分SQL都比较简单,偶尔有复杂的SQL,通常也比普通开发人员写的要好。
做性能优化,可以直接用jprofiler等工具在java端分析,偶尔拿个SQL在PLSQL Developer/TOAD中分析一下执行计划。
我们公司,用hibernate的项目,遇到性能优化都是开发人员顶上,而那些大量用PLSQL的项目,通常需要DBA全程参与优化
简单来说,就是因为我们很懒,所以我们会一直寻找能帮我们减轻工作量的东西。
因此,hibernate才能被社区广泛接受,这些团队选用hibernate到底是因为什么原因呢?
1.hibernate是一个orm框架,可以自动完成object和关系数据库之间的转换,加速开发。
这一点就是hibernate最大的特色,不管以前有没有玩过jdbc,看到了hibernate的hello world演示之后估计没有不赞叹的:“操作数据库怎么可能这么简单,hibernate简直是从火星来的哦。”
2.hibernate可以跨数据库。
这一点其实是实现了orm的后遗症,为了实现一个通用orm,就必须兼容主流的数据库,如果hibernate只能在某一个数据库上跑。那它肯定不会有目前的成就。
结果这一点就变成了很多产品开发的基础,这些产品只需要关注自己的业务,不需要考虑在不同的数据库之间进行迁移了,一切底层都交给hibernate,只做好自己擅长的事情,花最少的时间获得最大的价值。
3.hibernate上面附着了一大堆的扩展,hibernate-validator可以做数据校验,hibernate-search可以玩全文检索,hibernate-shard可以做水平分表。
随着不断的发展,hibernate俨然已经发展出一套产品线了,似乎我们只要选择了hibernate,就很容易获得上面说到得这些额外功能,那么到底是自己从头搞起比较爽呢?还是借助社区的力量比较容易呢?一般人还是会选择站在巨人的肩头的,如果所有人都喜欢自己玩,那开源社区也不会这么火了。
毫不脸红的夸完之后,下面是hibernate的问题:
1.封装严重,不容易理解底层实现,导致出现了问题不容易排查。
这个确实无可奈何,它做的太复杂了,但是纵观orm系列,openjpa之类的jar包大小也是在2m左右,这也就说明orm本身是复杂的,选用orm就意味着要负担它的复杂性,如果不愿意付出学习成本,还是选用更简单的实现比较好。简单实现意味着无法满足上述的优点,正所谓鱼与熊掌不可兼得,大家要在实际选型过程中仔细权衡才行。
2.有些人认为hibernate效率极其低下,无法应付庞大数据量的操作。
众所周知的情况是,系统的瓶颈往往会出现在数据库一端,因为我们可以搞20几台web服务器集群,但是加db server却不是那么容易的,一般都要经过水平分表才能实现这类需求。
而对于这种特种应用,说是用hibernate完成关键环节显然是笑话,咱们也不用多说了,还是采用专用的技术去搞定。
反过来,hibernate是否可以应对一般的应用呢?答案是肯定的,因为hibernate仅仅是在jdbc上进行的封装,只是自动处理了数据类型转换,并对每次操作都实现批量处理,相对一般的程序员来说, hibernate所实现的批量处理显然更高一些,与其让那些对数据库一知半解的人去写sql,反倒不如直接用hibernate还来的方便。
一家之言,万望各位指教
评论
96 楼
skcmm
2011-03-18
使用开源框架、从中学习人家的OO对象与数据库操作的思想,让程序员更多专注于业务 解决普遍性问题 才是初衷
95 楼
田耕信息技术
2011-02-28
yawei 写道
elmar 写道
xyz20003 写道
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.
Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.
After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.
At this point, you realize this is just another F**KING ORM.
使用框架,能快速解决某方面的问题,但同时也给别方面造成更大的困难。它可能在这方面灵活了,但在别一方面却显得笨拙。在这方面开发有效率了,但在另一方面却是负担。
94 楼
田耕信息技术
2011-02-28
yawei 写道
elmar 写道
xyz20003 写道
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.
Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.
After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.
At this point, you realize this is just another F**KING ORM.
没用过Habernate,只知道最基本的功能就是ORM。不过我个人喜欢用SQL语句来解决执行效率问题,而Habernate是解决开发效率问题,这两者还是有不小差异的。
另外,跨数据库的问题,在金融电信等领域,别说跨数据库,连数据库的版本号及其所在的LINUX主机环境都不敢动,一个小小的配置都可能导致灾难性的后果。所以说Habernate与跨数据库放在一起作为它的优点,这恐怕绝对不是原作者的本意,而是一些软件开发者宣传自己产品卖点的一种策略。实际应用中,大多数是些无关紧要的数据库才要考虑移植。
真正的跨数据库,我看还是多从标准SQL语句方面入手吧。
93 楼
yawei
2011-02-01
elmar 写道
xyz20003 写道
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.
Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.
After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.
At this point, you realize this is just another F**KING ORM.
92 楼
elmar
2011-01-30
xyz20003 写道
外边随处可见的产品宣传“采用了hibernate,可以运行在目前所有的主流数据库上。”试想一下,如果自己开发一套基于数据库存储的产品,是选择自己实现兼容所有数据库呢?还是用hibernate?
我会选择只使用最标准的sql而不会用hibernate。
91 楼
ppgunjack
2011-01-29
跨数据库是种理想而已,经历的几个产品都做到了操作系统可移植,唯独数据库不能动
Hibernate要能算可靠的跨数据库方案,那jdbc都能算了,衡量可用性不是存取数据就完事了
企业用户关心的就是数据,至于oo,ssh,可移植客户关心吗?只有打单的乙方关心
开源的实现又不承担升级后对api的冲击和客户支持
企业应用还是商业db为王,商业中间件次之,然后是服务器厂商,看看几个最重要的开源现在都握在那些厂商手里,都是数据库厂商
与其强求dba学hibernate,不如要求程序员多学学数据库更合理。dba是管整个数据系统安危可靠,干嘛为了程序员的dao的选型又学java又学hibernate?
不要指望把扩缩依赖orm,应该更多考虑orm是否影响扩缩方案
Hibernate要能算可靠的跨数据库方案,那jdbc都能算了,衡量可用性不是存取数据就完事了
企业用户关心的就是数据,至于oo,ssh,可移植客户关心吗?只有打单的乙方关心
开源的实现又不承担升级后对api的冲击和客户支持
企业应用还是商业db为王,商业中间件次之,然后是服务器厂商,看看几个最重要的开源现在都握在那些厂商手里,都是数据库厂商
与其强求dba学hibernate,不如要求程序员多学学数据库更合理。dba是管整个数据系统安危可靠,干嘛为了程序员的dao的选型又学java又学hibernate?
不要指望把扩缩依赖orm,应该更多考虑orm是否影响扩缩方案
90 楼
DOCDOC
2011-01-29
ppgunjack 写道
adaikiss 写道
javazeke 写道
有多少项目大到要换数据库的,,,炒作炒作就好了嘛。。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
大的项目别说换数据库,数据库版本都不会动,连着固定配置的主机和固定版本的OS一起打包
如果因为主机退市,带来的OS和主机升级会立项成立项目组专门进行移植和测试
现在系统自己实现了类似规则引擎的东西,问为啥不用jrule或者drools一类的成型的东西,曰,那时还没什么人用java
也找不到这些
企业级的产品,Linux这种背景尚且花了这么长时间,不要说其他的东西,如果用hibernate能降低很大成本的,说明原来成本本就不大
这要看情况了,如果你只是做个旧项目的outsource, 那自然不需要考虑跨数据库。
89 楼
ppgunjack
2011-01-28
adaikiss 写道
javazeke 写道
有多少项目大到要换数据库的,,,炒作炒作就好了嘛。。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
大的项目别说换数据库,数据库版本都不会动,连着固定配置的主机和固定版本的OS一起打包
如果因为主机退市,带来的OS和主机升级会立项成立项目组专门进行移植和测试
现在系统自己实现了类似规则引擎的东西,问为啥不用jrule或者drools一类的成型的东西,曰,那时还没什么人用java
也找不到这些
企业级的产品,Linux这种背景尚且花了这么长时间,不要说其他的东西,如果用hibernate能降低很大成本的,说明原来成本本就不大
88 楼
supben
2011-01-28
哥们,你用了top
还想让hibernate帮你跨数据库?
还想让hibernate帮你跨数据库?
87 楼
DOCDOC
2011-01-28
adaikiss 写道
javazeke 写道
有多少项目大到要换数据库的,,,炒作炒作就好了嘛。。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
如果基于自己的解决方案平台给客户做项目,多数据库的适应性还是非常非常重要的。
86 楼
adaikiss
2011-01-28
javazeke 写道
有多少项目大到要换数据库的,,,炒作炒作就好了嘛。。
如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......
85 楼
woshihlp
2010-05-04
学习了。。
心得:
做大项目,开发的团队大,用hibernate+反范式设计的数据库可从各方面保障开发效率,但是测试起来得谨慎了。。。
然后hibernate的多数据库支持,真换数据库了可不像说的那么轻松,要看做的功能用的HQL语句是不是大多不用改。。。
心得:
做大项目,开发的团队大,用hibernate+反范式设计的数据库可从各方面保障开发效率,但是测试起来得谨慎了。。。
然后hibernate的多数据库支持,真换数据库了可不像说的那么轻松,要看做的功能用的HQL语句是不是大多不用改。。。
84 楼
ssuupv
2010-04-30
aguai0 写道
哥们的头像挺有个性的
说我的吗?
83 楼
icewubin
2010-04-30
ssuupv 写道
抛出异常的爱 写道
icewubin 写道
anky_end 写道
hibernate相对比较难以调试的地方就在于他的n+1
比如某个操作缓慢,要从满屏的sql中寻找出执行缓慢的sql不太轻松。
比如某个操作缓慢,要从满屏的sql中寻找出执行缓慢的sql不太轻松。
利用工具很容易打出每一句执行的时间。
别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。
到plsql有时不准,同时一条语句,同样数据量,在生产环境中有时运行700-30000MS之间不等。差别相当的大。
生产环境会受OS和db的缓存的影响的。
82 楼
抛出异常的爱
2010-04-30
ssuupv 写道
抛出异常的爱 写道
icewubin 写道
anky_end 写道
hibernate相对比较难以调试的地方就在于他的n+1
比如某个操作缓慢,要从满屏的sql中寻找出执行缓慢的sql不太轻松。
比如某个操作缓慢,要从满屏的sql中寻找出执行缓慢的sql不太轻松。
利用工具很容易打出每一句执行的时间。
别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。
到plsql有时不准,同时一条语句,同样数据量,在生产环境中有时运行700-30000MS之间不等。差别相当的大。
plsql不准的话。。。。
loadrunner吧
个人认为loadrunner有点重。
81 楼
aguai0
2010-04-30
哥们的头像挺有个性的
80 楼
ssuupv
2010-04-30
HIB性能优化办法。其实跟JDBC性能优化办法。基本过程是
1.客户投诉慢
2.根据投诉慢功能点,查到性能问题代码点(其中这点蛮难的。我们一般都是客户说慢了,我们才去到指定代码跟踪。在开发环境不容易被发现)
3,针对问题点,如果是sql的语句。或者数据库一些设置问题。如果是数据库设置问题我想HIB跟JDBC区别不大吧,如果是sql语句。我想会HIB的人。基本上能控制HIB写的代码。转换出来的SQL是什么样,优化HIB代码也是比较容易的。所以HIB一般性能优化是没有问题。
其实HIB性能不好,还是不能直接调用数据库专属的。有些专属对环境对性能提升比较明显。
最后一点就是HIB表设计,跟JDBC表设计。宗旨是不一样的,有些地方是完全相背的。
1.客户投诉慢
2.根据投诉慢功能点,查到性能问题代码点(其中这点蛮难的。我们一般都是客户说慢了,我们才去到指定代码跟踪。在开发环境不容易被发现)
3,针对问题点,如果是sql的语句。或者数据库一些设置问题。如果是数据库设置问题我想HIB跟JDBC区别不大吧,如果是sql语句。我想会HIB的人。基本上能控制HIB写的代码。转换出来的SQL是什么样,优化HIB代码也是比较容易的。所以HIB一般性能优化是没有问题。
其实HIB性能不好,还是不能直接调用数据库专属的。有些专属对环境对性能提升比较明显。
最后一点就是HIB表设计,跟JDBC表设计。宗旨是不一样的,有些地方是完全相背的。
79 楼
ssuupv
2010-04-30
抛出异常的爱 写道
icewubin 写道
anky_end 写道
hibernate相对比较难以调试的地方就在于他的n+1
比如某个操作缓慢,要从满屏的sql中寻找出执行缓慢的sql不太轻松。
比如某个操作缓慢,要从满屏的sql中寻找出执行缓慢的sql不太轻松。
利用工具很容易打出每一句执行的时间。
别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。
到plsql有时不准,同时一条语句,同样数据量,在生产环境中有时运行700-30000MS之间不等。差别相当的大。
78 楼
hjtracy1
2010-04-26
个人认为java这种面向对象的高级语言纯粹使用jdbc不太现实。使用orm框架确实能加快开发速度,保证程序员有充足的时间处理业务逻辑而不是底层数据库代码的编写
77 楼
jasonshi
2010-04-22
myreligion 写道
hibernate其实还有一个不足:对DBA不友好!
严重同意,这玩意简直是抢DBA的饭碗。
用了hibernate,大部分SQL都比较简单,偶尔有复杂的SQL,通常也比普通开发人员写的要好。
做性能优化,可以直接用jprofiler等工具在java端分析,偶尔拿个SQL在PLSQL Developer/TOAD中分析一下执行计划。
我们公司,用hibernate的项目,遇到性能优化都是开发人员顶上,而那些大量用PLSQL的项目,通常需要DBA全程参与优化
发表评论
-
2010年11月27日周六去beijing open party讲讲jbpm4,有兴趣的话请过来一同聊聊。
2010-11-24 18:00 2697Hi All, 打算2010年11月27日下午13 ... -
轻量级工作流引擎jBPM 4.4正式发布
2010-07-20 19:31 5593jBPM-4.4于2010年7月19日正式发布。 jBP ... -
拖延一个多月后,jBPM-4.4发布CR1候选版
2010-07-15 22:06 2254Alejandro太谨慎了,发布jBPM-4.4之前还搞了一个 ... -
jBPM-4.3所需的最小依赖库列表
2010-06-18 17:06 4989这个问题被问到的次数太多了,无可奈何,只好花点儿时间整理一下。 ... -
jbpm4experiment——基于jbpm4的试验性项目
2010-05-31 14:15 5268官方的发布以稳重为主,所以也让人感觉步伐迟缓,自己建一个项目则 ... -
jBPM 4.4发布日期暂定于2010年6月4日
2010-05-24 09:51 2674jbpm官方终于传来好消息,jBPM 4.4可能在下月初发布。 ... -
jBPM 创始人发布BPMN原生引擎Activiti-5.0-alpha1
2010-05-20 09:21 5634Tom Baeyens也就是jBPM的原作者,离开了Red H ... -
寻求重现jbpm4.3中executionId映射错误的场景
2010-04-27 10:56 2554目前测试的结果是hibernate-3.2.1.ga以及之前 ... -
感受jBPM的动荡,想为jBPM4创建一个社区版的分支
2010-04-19 08:58 4952jBPM4的发展遇到了瓶颈,官方已经有一个多月没有更新代码了, ... -
跟我学工作流——jBPM4视频教程(免费)
2010-03-06 15:40 29546新的一年,为了让工作流方面的初学者更快上手开发,我们录制了jB ... -
jBPM-4.x常见问题解决方案FAQ
2010-01-22 09:18 3017这段时间整理的jBPM-4.x常见问题以及解决方案,希望帮助对 ... -
轻量级工作流jBPM-4.3官方“开发指南”中文版
2009-12-30 13:41 4427jBPM-4.3这次升级的重头戏都放在开发指南里了,添加的最大 ... -
轻量级工作流jBPM-4.3官方“用户手册”中文版
2009-12-30 11:25 3483jBPM-4.3准时发布,这次用户手册修改不大,主要是换换xm ... -
谁应该用流程设计器
2009-11-23 12:44 1864谁应该用流程设计器 ... -
数据建模与业务建模
2009-11-20 09:43 2412数据建模与业务建模 无论是企业信息系统还是web网站,各种大 ...
相关推荐
hibernate第一个hibernate
这是hibernate 的超级简单的例子,只有一个持久化对象和一个辅助类,还有一个测试类,对于初学者很有参考价值
hibernate需要的10个jar包.zip ,有需要的童鞋可以下载。
hibernate一对一的关系hibernate一对一的关系hibernate一对一的关系hibernate一对一的关系hibernate一对一的关系hibernate一对一的关系
Hibernate所需要的jar包,版本为hibernate-distribution-3.6.0.Final
Hibernate映射文件可选配置大全,协助开发很给力
hibernate 资料hibernate 资料hibernate 资料hibernate 资料
学习HIbernate的第一个例子,便于初学者入门
hibernate框架一对一测试案例,第四篇,使用于新手
Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库
Hibernate、Spring和Struts工作原理及使用理由
简单的hibernate连接,适合新手练习连接的使用,拍我
Hibernate不得不注意的问题,以及Hibernate的数据源
最简答的一个Hibernate工程
Hibernate 是一个开源的O/R mappimg的框架,基于JDBC提供了一种持久性数据管理的方案,相对于EntityBean来说是相当轻量级的。由于Hibernate是基于 JDBC的,所以它的数据库查寻的能力相对于CMP来说也是异常强大的,...
Hibernate构建一个CURD的程序
hibernate3hibernate3hibernate3hibernate3hibernate3hibernate3hibernate3hibernate3
加入了hibernate框架的javaWeb项目,里面包含了一对多的典型配置
hibernate的一个简单例程。配套如何搭建Hibernate框架的搭建和简单的使用
hibernate框架开发需要的jar