|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-23
linliangyi2007 写道 lizhilin 写道 xyz20003 写道 夜是天堂 写道 首先我只想说明有些场景Hibernate是不适用的，并没有全盘否定Hibernate的意思，事实上我自己很多项目都用了Hibernate，包括当前的项目。
如果非要说一个高并发的例子，新浪，搜狐肯定是的，当然我不能断定他们肯定不用Hibernate，但是即使用，也是有限的地方。 再次强调，我没有要炸死Hibernater的意思，我只是表达一些看法而已:)  原谅我这里的较真，因为“高并发”，“大项目”这些词实在太雷人，很容易被一些人作为把柄恶意引用，然后就会出现一群人因为对这些名词的理解不同而引发无谓的争吵，实际上，只要稍微用定语划一个范围就可以免去很多麻烦，毕竟群众的眼睛是雪亮的，只要讲的清楚大家都能明辨是非。
其实在下一直对千万级数据，分库分表的应用心驰神往，可以一直无缘得见，不知道这种项目里的组织机构是如何划分的，是否由dba前期一次性完成所有设计和封装工作，剩下的只要外围应用去调用就可以了。感觉对外部应用的限制很大，在这种项目里玩岂不是很无聊，每天的工作只是调用封装好的东西而已。 
想想sns项目 访问量和数据量 是否由dba前期一次性完成所有设计和封装工作 ----我是很期待这样 但是现实情况是 完全自己做 当然完全靠数据库肯定不行的 这就是其他方面的问题了 这就更假了，你知道现在sns的主流数据库是啥吗？不是SQL了拜托，是对象型数据库Apache Cassandra,FaceBook用的。 我们现在也开始对这块的研究转型。 就算是国内传统的大型SNS，对数据库的优化重点——可以给你透露一下——是自己设计的中间层的查询路由，而不是基于SQL的优化，因为对于大并发量的访问，SQL优化带来的性能杯水车薪啊！！ 好吧 你是大公司 你们技术实力强 你赢了 |
| 返回顶楼 | |
|
发表时间：2010-03-23
linliangyi2007 写道 seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这就是设计问题了，在我们公司，设计都通不过，还优化个啥啊！！ 呵呵，遗留问题。。不是说能改就能改的。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
呃....
越来越发现je不适合讨论问题了。。 闪了，写代码去了 |
| 返回顶楼 | |
|
发表时间：2010-03-23
最后修改：2010-03-23
抛出异常的爱 写道
因为大家都认为 hibernate是个ORM框架 但是它不是.
lizhilin 写道
我遇到过的 针对mysql 优化sql use index语句hql不支持 需要自己扩展 为了性能 有些复杂的写法 只能使用原生sql 二级缓存可以满足一般需求 但对于查询缓存没找到很好的扩展机制 很多时候为了性能 查询缓存要自己做
fireflyc 写道
我来说一下我用的一些比较好的实践 1. 禁止多对多关系，改用一对多的关系。 2. 使用HQL语句进行查询 3. 把hibernate当做一个高级的SQL封装来用。
flootball 写道
还在考虑Hibernate性能啊！
现在都考虑直接走磁盘了。这样可以去掉日志，锁，认证, 索引文件可以大大的减少。
javabrother 写道
妈妈的，最近两个面试，都是问道搞并发，海量数据的处理！
数据库的调优， 搞灾了............
flyinglife 写道
坦白说，碰到复杂或者多表联合查询，我都先写原生sql,然后再用hql实现同样的sql。性能问题没怎么碰到。
moyue 写道
godson_2003 写道
对于大表的N+1问题 我们在设计数据库的时候为什么不适当的冗余呢？
产品表完全可以冗余产品分类 解决办法后很多 支持你的想法，冗余设计其实是一个博弈的问题，有时我们不能太技术，总是考虑要做到没有冗余，现在硬盘又不贵，相比连接表造成的性能降低，还不如冗余设计呢，就说产品表，产品类别的改动一般都不大，即便产品再多，相比产品的查询和增加，类别的变动几率要小的多。
tibetjungle 写道
性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。
Angel_Night 写道
确实hibernate性能不好是听来的...
我技术水平很低..平时工作,hibernate最多用来做增删改查...还是单表 稍微复杂的查询就视图...表多就物化视图... 开发中根本没遇到过性能瓶颈...
anky_end 写道
技术风险，就是这样。
产品化的项目很有必要上hibernate，项目化的，那么就应该考虑下实际情况。 基本没有hibernate做不到的事情，但是想做好很难。 从各个公司的知识积累来说，对数据库的构造、sql的优化都是有相当丰富经验的。对j2ee这块就未必了
Joo 写道
如果是纯粹的抓数据，抓到业务层做处理，<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>或者少量的写，用Hibernate没问题。但我们有一大半的业务逻辑都封装在Oracle pkg中，这已经不是sql是否能优化的问题了，在业务本身就跟数据高耦合的情况下，多一层ORM不如直接写pkg，况且还能使用PL/SQL进行本地静态编译优化。
gdpglc 写道
夜是天堂 写道
看上去楼主应该没做过什么高并发的系统。
对一个高并发系统来说，数据库往往是整个系统的瓶颈。可以说每一条SQL语句都是优化的对象。 实际操作中，开发人员会拿着可能用到的SQL语句与DBA进行充分沟通。从这一点就可以解释，为什么说Hibernate对DBA不友好（你总不能拿着映射关系去找DBA吧）。 另外一点，Hibernate动不动就做join,对高并发系统来说这是一件很奢侈的事情。往往采取数据冗余的方式。 至于数据库迁移，楼主做的项目应该不少，碰到过多少这样的案例？ 当然，Hibernate是一个非常好的东西，对一般项目来说确实能省很多工作量，对高并发系统来说也不是完全不能用，用Hibernate来做简单对象的增、删、改是没有任何问题的。 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？
lizhilin 写道
xyz20003 写道
夜是天堂 写道
首先我只想说明有些场景Hibernate是不适用的，并没有全盘否定Hibernate的意思，事实上我自己很多项目都用了Hibernate，包括当前的项目。
如果非要说一个高并发的例子，新浪，搜狐肯定是的，当然我不能断定他们肯定不用Hibernate，但是即使用，也是有限的地方。 再次强调，我没有要炸死Hibernater的意思，我只是表达一些看法而已:) 原谅我这里的较真，因为“高并发”，“大项目”这些词实在太雷人，很容易被一些人作为把柄恶意引用，然后就会出现一群人因为对这些名词的理解不同而引发无谓的争吵，实际上，只要稍微用定语划一个范围就可以免去很多麻烦，毕竟群众的眼睛是雪亮的，只要讲的清楚大家都能明辨是非。其实在下一直对千万级数据，分库分表的应用心驰神往，可以一直无缘得见，不知道这种项目里的组织机构是如何划分的，是否由dba前期一次性完成所有设计和封装工作，剩下的只要外围应用去调用就可以了。感觉对外部应用的限制很大，在这种项目里玩岂不是很无聊，每天的工作只是调用封装好的东西而已。 想想sns项目 访问量和数据量 是否由dba前期一次性完成所有设计和封装工作 ----我是很期待这样 但是现实情况是 完全自己做 当然完全靠数据库肯定不行的 这就是其他方面的问题了
ztka 写道
企业应用，例如ERP,物流系统，高并发不是问题，问题在于及时性，你对某个东西做了修改，其他地方要立即看到。所以某些缓存设计不大适合企业系统。
nighthawk 写道
我认为hibernate真正的尴尬不是性能问题，而是他最初定位的ORM，面向对象。
他期望大家忽略关系型数据库的现实，去构造一个面向对象以及领域模型的一个美好蓝图。 但其实结果不容乐观，在依然是关系数据库横行的今天，光靠hibernate可能很难扭转这个格局。
nighthawk 写道
firebody 写道
nighthawk 写道
我认为hibernate真正的尴尬不是性能问题，而是他最初定位的ORM，面向对象。
他期望大家忽略关系型数据库的现实，去构造一个面向对象以及领域模型的一个美好蓝图。 但其实结果不容乐观，在依然是关系数据库横行的今天，光靠hibernate可能很难扭转这个格局。 hibernate没有让你不去关心这些东西，而是让你在开发的时候可以用这个工具去提高效率，但不是说让你不关心这底层的东西。 开发效率提高，业务问题很容易解决了，然后让你有更多的精力去关心底层的东西：比如性能问题等等。 现在有一帮子这样的人出来跳，以为hibernate是可以让自己偷懒不用多努力学习底层的东西就可以混饭吃，结果发现事实并不是那样，认为仅仅是看起来很美，结果还得让自己关注底层的东西才能解决性能问题，所以就气急败坏的宣布：hibernate不适合用来做大项目开发，不适合做高并发开发。 对于这帮子人，我奉劝一句：你在家丢人我不管，但是出来献丑那就是你的不对了。 我很赞同你的观点。 对于某些人而言，他希望快速上手，这个使用动机是良好的。 希望在整个团队当中做到跟大家水平同步，leader也很乐意，框架化便于管理嘛。 而且在小型团队当中也能取得一定的效果，但接下来问题来了。 如果没有经历过早期的裸sql开发时期（或者说没有一点SQL基础，数据库基本调优）。仅仅期望把它当成一个快速上手的工具，并且希望它取代并且绕开SQL， 那结果自然是失望了，这里就会出现所讨论的性能问题。
|
| 返回顶楼 | |
|
发表时间：2010-03-23
今天特别出来针尖对麦芒似的反驳楼上几位，可能言语上让人不爽了，我道歉。
但不这样针对性的反驳，大家都会有一种错觉，是不是大系统都是一张表1000w数据，一次SQL要join n张的，需要多高深的优化。 包括我和我身边的朋友之前也都有这样的想法。但实际上，越是大型的应用，数据库结构越趋于简单化。 这里不希望给大家留一个错误的影响：hibernate不适合大应用，不适合高并发。这种自己臆想出来的观念，是对自己的错误暗示，也容易误导别人。因此坚决予以打击。 话说回来，SQL优化重要不？hibernate什么时候不适合用? SQL优化的重要性不会出现在新生代的系统中，而都是在老系统中存在的。是随着应用数据的日积月累，发现约有SQL性能慢了，需要调优的，而不是在一开始就调优，那只能说设计有问题了。 hibernate不适用的地方通常也是对旧有系统的兼容性上的（如jar包版本冲突，旧数据库设计不是OO的，关联太乱），但更多是技术外的因素，如项目组成员不熟悉Hibernate；用户对Hibernate的开源代码健壮性质疑（一般是老有钱的大客户，动不动就是买正版服务的那种）。 说一千道一万，还是人的问题。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
引用 你也可以问问天涯这样的大网站，他们是用缓存技术，还是让用户每次访问去查SQL哈~~~拜托，数据库就是存储为主的！ 别提天涯了。。。。 早年从上天涯学技术起家的。 这两年不清楚。。。 当年技术那叫一个烂。。。。。 还真别说很有可能是让用户访问SQL |
| 返回顶楼 | |
|
发表时间：2010-03-23
抛出异常的爱 写道 抛出异常的爱 写道 因为大家都认为 hibernate是个ORM框架 但是它不是. 它是一个以数据库为数据源的缓存系统 lizhilin 写道 我遇到过的 针对mysql 优化sql use index语句hql不支持 需要自己扩展 为了性能 有些复杂的写法 只能使用原生sql 二级缓存可以满足一般需求 但对于查询缓存没找到很好的扩展机制 很多时候为了性能 查询缓存要自己做 特别的查询多的话还是不用hibernate方便一些。 PS：为了use index不得不把一些表拆成 one to one 的方式来作。。。那样子就可以把idex用的合适一些了。 fireflyc 写道 我来说一下我用的一些比较好的实践 1. 禁止多对多关系，改用一对多的关系。 2. 使用HQL语句进行查询 3. 把hibernate当做一个高级的SQL封装来用。 最后一点看起来简单 但会发展出更多的问题 flootball 写道 还在考虑Hibernate性能啊！
现在都考虑直接走磁盘了。这样可以去掉日志，锁，认证, 索引文件可以大大的减少。 日志，锁，认证，索引。。。。。。。这是把业务封装进数据库， 使大多数应用不用考虑这些。 如果去掉。还要自己写这些东西 javabrother 写道 妈妈的，最近两个面试，都是问道搞并发，海量数据的处理！
数据库的调优， 搞灾了............ 又要马儿跑又要马儿不吃草。 flyinglife 写道 坦白说，碰到复杂或者多表联合查询，我都先写原生sql,然后再用hql实现同样的sql。性能问题没怎么碰到。
大多数查寻都可以用视图来实现。可以去掉复杂hql（我们系统中有DBA来写这部分） moyue 写道 godson_2003 写道 对于大表的N+1问题 我们在设计数据库的时候为什么不适当的冗余呢？
产品表完全可以冗余产品分类 解决办法后很多 支持你的想法，冗余设计其实是一个博弈的问题，有时我们不能太技术，总是考虑要做到没有冗余，现在硬盘又不贵，相比连接表造成的性能降低，还不如冗余设计呢，就说产品表，产品类别的改动一般都不大，即便产品再多，相比产品的查询和增加，类别的变动几率要小的多。 冗余尽量少用。。。用的越多，程序越复杂，异常可能就最多。 whaosoft 写道 有的人只能hibernate当 返回对象的工具用了 所以当然以为hibernate这不行那不行了 和他们着什么急呢
tibetjungle 写道 性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。 hibernate可以以业务为前提产生对应的缓存。 其实IO总数量的是在业务范围内减少次数的。。。。。 Angel_Night 写道 确实hibernate性能不好是听来的...
我技术水平很低..平时工作,hibernate最多用来做增删改查...还是单表 稍微复杂的查询就视图...表多就物化视图... 开发中根本没遇到过性能瓶颈... 这就是hibernate的最佳用法 firebody 写道 tibetjungle 写道 性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。 这我就不懂了，驱动表你sql可以自己选择，hql你也可以自己选择。 这又有啥区别呢？ 最有效的索引没用，这个问题从两个方面来看，如果你必须强迫用某个索引，那么这里你可能只能选择hibernate的sql查询了，否则，那就和你写sql查询没有任何区别了，你该去查查有效索引为何没被使用的真正原因。 正如我说的，hibernate不能解决所有问题，这些问题你就特殊处理好了，一点问题都没有，甚至连皱眉头都没必要。 anky_end 写道 技术风险，就是这样。
产品化的项目很有必要上hibernate，项目化的，那么就应该考虑下实际情况。 基本没有hibernate做不到的事情，但是想做好很难。 从各个公司的知识积累来说，对数据库的构造、sql的优化都是有相当丰富经验的。对j2ee这块就未必了 有些公司美工力量强，有些公司行业业务精，有些公司产品化成度高。 好的Oracle 的 DBA可以用钱买的到。是行业共识。想打破很难。 Joo 写道 如果是纯粹的抓数据，抓到业务层做处理，或者少量的写，用Hibernate没问题。但我们有一大半的业务逻辑都封装在Oracle pkg中，这已经不是sql是否能优化的问题了，在业务本身就跟数据高耦合的情况下，多一层ORM不如直接写pkg，况且还能使用PL/SQL进行本地静态编译优化。
原始项目迁移。。。就是个恶梦。。。。 至今没见过成功的hibernate项目 gdpglc 写道 夜是天堂 写道 看上去楼主应该没做过什么高并发的系统。
对一个高并发系统来说，数据库往往是整个系统的瓶颈。可以说每一条SQL语句都是优化的对象。 实际操作中，开发人员会拿着可能用到的SQL语句与DBA进行充分沟通。从这一点就可以解释，为什么说Hibernate对DBA不友好（你总不能拿着映射关系去找DBA吧）。 另外一点，Hibernate动不动就做join,对高并发系统来说这是一件很奢侈的事情。往往采取数据冗余的方式。 至于数据库迁移，楼主做的项目应该不少，碰到过多少这样的案例？ 当然，Hibernate是一个非常好的东西，对一般项目来说确实能省很多工作量，对高并发系统来说也不是完全不能用，用Hibernate来做简单对象的增、删、改是没有任何问题的。 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ 1. select new ResultBean(c.id ,c.name) from C c 与` from C c 有区别 2.这个问题出在设计上。。 根本上两个实体上没有联系时join的返回集是非常难以组织的。。。。 加了联系时有时又不正确的事常有发生。 设计变化又会引起其它的变化。。。。 一波又一波。。。。 冗余又是以牺牲代码量为代价的。。。 lizhilin 写道 xyz20003 写道 夜是天堂 写道 首先我只想说明有些场景Hibernate是不适用的，并没有全盘否定Hibernate的意思，事实上我自己很多项目都用了Hibernate，包括当前的项目。
如果非要说一个高并发的例子，新浪，搜狐肯定是的，当然我不能断定他们肯定不用Hibernate，但是即使用，也是有限的地方。 再次强调，我没有要炸死Hibernater的意思，我只是表达一些看法而已:) 原谅我这里的较真，因为“高并发”，“大项目”这些词实在太雷人，很容易被一些人作为把柄恶意引用，然后就会出现一群人因为对这些名词的理解不同而引发无谓的争吵，实际上，只要稍微用定语划一个范围就可以免去很多麻烦，毕竟群众的眼睛是雪亮的，只要讲的清楚大家都能明辨是非。
其实在下一直对千万级数据，分库分表的应用心驰神往，可以一直无缘得见，不知道这种项目里的组织机构是如何划分的，是否由dba前期一次性完成所有设计和封装工作，剩下的只要外围应用去调用就可以了。感觉对外部应用的限制很大，在这种项目里玩岂不是很无聊，每天的工作只是调用封装好的东西而已。
想想sns项目 访问量和数据量 是否由dba前期一次性完成所有设计和封装工作 ----我是很期待这样 但是现实情况是 完全自己做 当然完全靠数据库肯定不行的 这就是其他方面的问题了 新浪，搜狐的项目大多是给文编用的。。。。并发可能没你想象的大。 真正大的论坛又可以用路由分块使的信息产生地窖。。。。 我见过的真正并发大点的是个物流系统。。。。 见过别的项目有过千万级数据（导出文本大约四五个G）没有分库也没有分表。 全由程序员一个人说了算（当然其它人是以文编为主。） 改来改去。结构，技术。能用上都用上了。 为了一个双%%查寻终于用上了lucene 为了一个排重用上了布龙过滤器。 sns开心用的是memcached作的。。。 数据集大到了那个时候自然会有好用的技术给你用 之前不必太在意 ztka 写道 企业应用，例如ERP,物流系统，高并发不是问题，问题在于及时性，你对某个东西做了修改，其他地方要立即看到。所以某些缓存设计不大适合企业系统。
这个两个应用心跳式集群。 三四个应用共享session集群 最麻烦的是在你开发前没发现hibernate是个缓存的事实 集群失败的事也见过。 在线开发集群同步的事也作过。 。。。。。。。。 如此总总。令我认为hibernate根本上就不是个ormapping软件。 nighthawk 写道 我认为hibernate真正的尴尬不是性能问题，而是他最初定位的ORM，面向对象。
他期望大家忽略关系型数据库的现实，去构造一个面向对象以及领域模型的一个美好蓝图。 但其实结果不容乐观，在依然是关系数据库横行的今天，光靠hibernate可能很难扭转这个格局。 终于有人同意我的观点了。。。。 nighthawk 写道 firebody 写道 nighthawk 写道 我认为hibernate真正的尴尬不是性能问题，而是他最初定位的ORM，面向对象。
他期望大家忽略关系型数据库的现实，去构造一个面向对象以及领域模型的一个美好蓝图。 但其实结果不容乐观，在依然是关系数据库横行的今天，光靠hibernate可能很难扭转这个格局。 hibernate没有让你不去关心这些东西，而是让你在开发的时候可以用这个工具去提高效率，但不是说让你不关心这底层的东西。 开发效率提高，业务问题很容易解决了，然后让你有更多的精力去关心底层的东西：比如性能问题等等。 现在有一帮子这样的人出来跳，以为hibernate是可以让自己偷懒不用多努力学习底层的东西就可以混饭吃，结果发现事实并不是那样，认为仅仅是看起来很美，结果还得让自己关注底层的东西才能解决性能问题，所以就气急败坏的宣布：hibernate不适合用来做大项目开发，不适合做高并发开发。 对于这帮子人，我奉劝一句：你在家丢人我不管，但是出来献丑那就是你的不对了。 我很赞同你的观点。 对于某些人而言，他希望快速上手，这个使用动机是良好的。 希望在整个团队当中做到跟大家水平同步，leader也很乐意，框架化便于管理嘛。 而且在小型团队当中也能取得一定的效果，但接下来问题来了。 如果没有经历过早期的裸sql开发时期（或者说没有一点SQL基础，数据库基本调优）。仅仅期望把它当成一个快速上手的工具，并且希望它取代并且绕开SQL， 那结果自然是失望了，这里就会出现所讨论的性能问题。 高手出来，以一敌百，呵呵 |
| 返回顶楼 | |
|
发表时间：2010-03-23
linliangyi2007 写道 seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这就是设计问题了，在我们公司，设计都通不过，还优化个啥啊！！ 有啥问题。 从这就能看出问题了。 hibernate是好东西， 好东西也不能哪都用啊 |
| 返回顶楼 | |
|
发表时间：2010-03-23
linliangyi2007 写道 seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这就是设计问题了，在我们公司，设计都通不过，还优化个啥啊！！ 这就是设计问题了？？估计你不是搞企业开发的，现有的SAP,ORACLE,JDE的ERP，都是这样设计。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
ztka 写道 linliangyi2007 写道 seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这就是设计问题了，在我们公司，设计都通不过，还优化个啥啊！！ 这就是设计问题了？？估计你不是搞企业开发的，现有的SAP,ORACLE,JDE的ERP，都是这样设计。 我搞企业开发，而且还搞SOA和ESB，做了一整套的系统结构。一个企业级系统，现在不是多表关联，恰恰是要合理切分，形成SOA服务点，这个说来话又长了~~~ 跟互联网差异确实挺大，但偏偏Hiberante在SOA的系统上特适合，因为整个企业总线都是面向消息对象的。 嗨~~都别纠结于技术了，SQL也好Hibernate也好，能做好应用就OK了。 这个帖子的渊源要上述到两个帖子了，一个面试官问应聘者，你了解Hibernate的嘛，结果应聘的很不屑的说Hiberante不适合大系统....总之他不屑学的意思，于是乎就有了一堆人的争论，接着又有一个帖子出现了，就是楼主发的。到后来才是这个帖子了。。。 任何技术都没有错，就看人怎么用了。 |
| 返回顶楼 | |
