|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-26
我现在感觉和robbin差不多,Hibernate 性能太低了.
HQL发明得也不台好. 比如删除数据,竟然要先查询出来 设计这样一个方法不就行了的 session.delete(Class.class,id); get都会做,真么就不会做删除,还有修改... Hibernate 的二级缓存简直是垃圾.保存个ID有什么用. 用的时候又要查,和没缓存一样的效果. 最后发现还是spring 的缓存拦截器好用. 唯一的优点,可以跨数据库. |
| 返回顶楼 | |
|
发表时间：2006-12-26
如果HQL足够强大，那么它就走入MS LINQ的道路了，可它好像不伦不类。
|
| 返回顶楼 | |
|
发表时间：2006-12-26
dogstar 写道 1.我想hql的出现是为了屏蔽数据库之间sql的差异，也就是为了跨数据库。如果你直接写sql的话，难保会写一些native sql.（虽然一般我们也不会轻易换数据库）
2.估计hibernate不赞成你老阅读它的sql，哈哈。（是够长够臭） 跨数据库。。。未免是得不偿失。 |
| 返回顶楼 | |
|
发表时间：2006-12-26
Readonly 写道 偶严重反对robbin对于HSQL的看法，如果没有HSQL的话，让偶回到过去那种写一个产品，要在N种数据库上调试不同的SQL兼容性，简直是噩梦啊。
COC就更没有啥话好说了，你完全可以给Hibernate加个COC plugin，只支持native PK，只支持1:N，只支持字段和数据库栏位同名。批评Hibernate不够自动化，就象批评手自一体的BMW比自动挡的KIA难用一样好笑... Hibernate生成的SQL倒是没有啥感觉，因为基本上hibernate.show_sql都是false，只有很特殊的调试情况下，才需要打开这个参数去看生成的sql是怎么样的吧？ 这种场景很有可能是坐家里拍脑袋想出来的，大部分应用都是基于一种数据库。 |
| 返回顶楼 | |
|
发表时间：2006-12-26
1，save(Foo f);不能通过f对象往里面传递哪些字段更新、哪些不更新；
严重同意，其实没必要将空数据写入数据库，一般很少将数据库中的数据更新为空，这是很不好的设计 cznc 写道 意思是如果在更新时有的字段没有更新就没必要对它的字段进行更新？ 可以通过在映射表里加入： dynamic-insert="true"
dynamic-update="true"
来实现的。 |
| 返回顶楼 | |
|
发表时间：2006-12-26
downpour 写道 Readonly 写道 downpour 写道 我们肯定希望采用一句HQL解决问题，但是此时问题来了，当你试图做SELECT department, count(employee.id) FROM .....这样的HQL时，在Java端，发现没有一个合适的对象可以映射。 从OO的角度，其实可以在Department这个类中加一个employeeSize来表示这种业务场景。但是好像Hibernate无法去做类似的映射。而iBatis在这个方面却灵活的多。 给一个构建函数： public class Department(Department d, Integer employeeSize) 然后写成这样： SELECT new Department(department, count(employee.id)) FROM ..... 不就OK了吗？ 我尝试过这种做法，不过记得好像以前调试的时候Hibernate报错啊。啥时候再调一把。 不过如果类似的业务场景中，我总觉得用构造函数不是一个很好的做法。因为可能一个构造函数只能满足单一的业务场景，如果现在再来一个类似的业务场景，这个构造函数就无能为力了。 现在有什么好的办法解决没有？ 我现在也碰到了这个问题，一个代表团Team里面有多个公司Company（companySet），一个company对应一个用户User，一个User里又有多个人Person（personSet）。 现在页面要做team列表处理，每一个team的信息里包含company数量，person数量，以前在页面直接用companySet、personSet来实现，速度吓死人。 |
| 返回顶楼 | |
|
发表时间：2006-12-26
smilerain 写道 我现在感觉和robbin差不多,Hibernate 性能太低了.
HQL发明得也不台好. 比如删除数据,竟然要先查询出来 设计这样一个方法不就行了的 session.delete(Class.class,id); get都会做,真么就不会做删除,还有修改... Hibernate 的二级缓存简直是垃圾.保存个ID有什么用. 用的时候又要查,和没缓存一样的效果. 最后发现还是spring 的缓存拦截器好用. 唯一的优点,可以跨数据库. 比如删除数据,竟然要先查询出来 设计这样一个方法不就行了的 session.delete(Class.class,id);？？ 上面这样类似的方法完全可以自己写 hibernate的二级缓存可不是你说的这样只保存id，看来你没有完全用好hibernate， 我的看法是凡是完全否定hibernate的，统统都是不会用hibernate的人。 hibernate是有缺点，但决不是你们嘴上说的那些，还有人说hibernate性能有问题，那也得看用在什么地方，怎么用，given king也说了hibernate适用于95％的需求，另外5%需要程序员自己解决的。凡是一棍子打死hibernate的人应该再去认真的学习学习hibernate |
| 返回顶楼 | |
|
发表时间：2006-12-26
ahuaxuan 写道 smilerain 写道 我现在感觉和robbin差不多,Hibernate 性能太低了.
HQL发明得也不台好. 比如删除数据,竟然要先查询出来 设计这样一个方法不就行了的 session.delete(Class.class,id); get都会做,真么就不会做删除,还有修改... Hibernate 的二级缓存简直是垃圾.保存个ID有什么用. 用的时候又要查,和没缓存一样的效果. 最后发现还是spring 的缓存拦截器好用. 唯一的优点,可以跨数据库. 比如删除数据,竟然要先查询出来 设计这样一个方法不就行了的 session.delete(Class.class,id);？？ 上面这样类似的方法完全可以自己写 hibernate的二级缓存可不是你说的这样只保存id，看来你没有完全用好hibernate， 我的看法是凡是完全否定hibernate的，统统都是不会用hibernate的人。 hibernate是有缺点，但决不是你们嘴上说的那些，还有人说hibernate性能有问题，那也得看用在什么地方，怎么用，given king也说了hibernate适用于95％的需求，另外5%需要程序员自己解决的。凡是一棍子打死hibernate的人应该再去认真的学习学习hibernate 同意，hibernate确实有很多缺点，比如不够灵活，性能不够好。但只要它的优点能够满足我的需求我就会用它。 谁告诉你们用hibernate就要靠它包打天下了。 |
| 返回顶楼 | |
|
发表时间：2006-12-26
downpour 写道 Hibernate在查询时，面对很多映射有时候显得很苍白。
例如有个业务场景，Department和Employee是一对多关系。现在我对Department进行分页查询，要求在显示的页面上同时显示每个Department中Employee的数量。这是一个很简单的业务场景，但是想象一下如何用hibernate进行映射？ 首先否定一种做法：hql：FROM Department department。然后针对每个department，去做department.getEmployees().size()。这样不仅会发送n＋1条SQL，而且性能太低。 我们肯定希望采用一句HQL解决问题，但是此时问题来了，当你试图做SELECT department, count(employee.id) FROM .....这样的HQL时，在Java端，发现没有一个合适的对象可以映射。 从OO的角度，其实可以在Department这个类中加一个employeeSize来表示这种业务场景。但是好像Hibernate无法去做类似的映射。而iBatis在这个方面却灵活的多。 可以用hql一句话写： select new DepartmentView(d.poin,count(e.poin)) from Department d inner join d.employeeSet group by d.poin. |
| 返回顶楼 | |
|
发表时间：2006-12-26
至少在中小规模的应用上，hibernate的性能还是非常不错的。至于某些特殊场合下，诸如需要在列表里显示某个部门的总员工数的，特殊处理一下也可以解决。
真正体会到hb带来的好处的，就是跨数据库！对于产品来讲，跨数据库是必须的，以针对不同目标客户选用不同的数据库。我现在就可以说，俺们的产品部署在任何HB支持的数据库上都没问题。 |
| 返回顶楼 | |
