谈谈Hibernate令人不爽的地方

正所谓“此一时，彼一时”嘛， ，说来说去，还是个场景问题，性能 vs 移植性...

用jrc sql，价格便宜量又足。

Hibernate生成的SQL确实不错，这方面我承认，但Hibernate把表名，字段名都自作主张加上了别名，看起来太难看了，阅读起来非常不友好。

hibernate.format_sql ＝ true

如果想要仔细看Hibernate生成的SQL语句，将format_sql设为true可以很大程度地减轻痛苦……


再加上这个的话：
hibernate.use_sql_comments ＝ true

个人认为 [可读性 + 可定位性] 会更好。

当然，这两个一起来的话也会造成SQL在console中显示的篇幅很大。例如：

/**
 * 以下是Hibernate在控制台中自动生成的log
 */

Hibernate:
    /* criteria query */ select
        this_.id as id88_0_,
        this_.flag as flag88_0_,
        this_.description as descript3_88_0_,
        this_.mobilizationDate as mobiliza4_88_0_,
        this_.recordId as recordId88_0_,
        this_.deptFromId as deptFromId88_0_,
        this_.deptToId as deptToId88_0_
    from
        Mobilization this_
    where
        this_.flag=?
    order by
        this_.id asc

Hibernate:
    /* load net.example.model.PersonnelRecord */ select
        personnelr0_.id as id91_0_,
        personnelr0_.flag as flag91_0_,
        personnelr0_.birthDate as birthDate91_0_,
        personnelr0_.deptId as deptId91_0_,
        personnelr0_.eduQualificationId as eduQuali5_91_0_,
        personnelr0_.firstWorkDate as firstWor6_91_0_,
        personnelr0_.gender as gender91_0_,
        personnelr0_.idNumber as idNumber91_0_,
        personnelr0_.nationalityId as national9_91_0_,
        personnelr0_.originDate as originDate91_0_,
        personnelr0_.politicalConditionId as politic11_91_0_,
        personnelr0_.socialRelation as socialR12_91_0_,
        personnelr0_.description as descrip13_91_0_,
        personnelr0_.jobPositionId as jobPosi14_91_0_,
        personnelr0_.jobTitleId as jobTitleId91_0_,
        personnelr0_.jobTypeId as jobTypeId91_0_,
        personnelr0_.personName as personName91_0_,
        personnelr0_.iconUrl as iconUrl91_0_,
        personnelr0_.officialFlagId as officia19_91_0_,
        personnelr0_.marriageFlagId as marriag20_91_0_,
        personnelr0_.personnelNumber as personn21_91_0_,
        personnelr0_.quitWorkDate as quitWor22_91_0_,
        personnelr0_.address as address91_0_,
        personnelr0_.cellPhoneNumber as cellPho24_91_0_,
        personnelr0_.email as email91_0_,
        personnelr0_.phoneNumber as phoneNu26_91_0_,
        personnelr0_.nativeLocation as nativeL27_91_0_
    from
        PersonnelRecord personnelr0_
    where
        personnelr0_.id=?

Hibernate:
    /* load net.example.model.Department */ select
        department0_.id as id81_0_,
        department0_.flag as flag81_0_,
        department0_.deptName as deptName81_0_,
        department0_.deptTypeId as deptTypeId81_0_,
        department0_.description as descript5_81_0_,
        department0_.deptNumber as deptNumber81_0_
    from
        Department department0_
    where
        department0_.id=?

Hibernate:
    /* load net.example.model.Department */ select
        department0_.id as id81_0_,
        department0_.flag as flag81_0_,
        department0_.deptName as deptName81_0_,
        department0_.deptTypeId as deptTypeId81_0_,
        department0_.description as descript5_81_0_,
        department0_.deptNumber as deptNumber81_0_
    from
        Department department0_
    where
        department0_.id=?

机器自动生成，而且还得考虑不能触犯到保留字（java sql 数据库自身），这样多的要求，还得易看！其实hibernate做得很好了，只是我们不知道他们所考虑的。

实现数据库兼容并不象你想象的那么难。：）
我做的平台软件在多种数据库上测试过，包括:Oracle9(10),SqlServer2000,MySql4(5),PostgreSQL8,
HyperSonic。
操作包括CRUD，查询也有比较复杂的。
兼容数据库的步骤如下：
1)数据库DDL是要自行处理的。当然可以借助PowerDesigner的自动转换数据库功能，虽然也有bug，其实主要无非就是一些数据类型的转换，手写也可。
2)CRUD之字段类型。JDBC的PreparedStatement已经帮你将所有的字段类型都封装了，不需要为了插入日期型等数据调用数据库本地的函数，ps.setDate()即可。
3)CRUD之SQL语法。ANSI SQL标准虽然贯彻得不够彻底，但常用的语法的确得到了一致认可。比如，表的左外连接在Oracle8里只有a.field1=b.feild2(+)这种方式，但在Oracle9以后，都支持标准的left outer join on语法了。这种语法在上述5种数据库都得到支持。其他的别名的语法也支持良好。
我碰到的一个比较搞的问题就是SQLserver2000种删除语句不能给表设置别名，即不能delete from TABLE a where a.id=?，去除别名无问题。
4)结果分页。这个的确是我碰到的最需额外处理等问题。我就是参考了hibernate的方法解决的。
5)ID生成问题。不同数据库有各自优化的方式，也可以使用通用的方式。也参考hibernate。
6)其他问题。比如Oracle里的hierachical query(connect by语句)在其他的数据库可能没有对等的实现方式，此时无法对此特性跨平台了。

这个问题有意思。我有同感。
没出现ORM之前就会有人觉得直接写SQL丑陋；现在又会有人觉得用ORM麻烦。
这真是事务发展的规律啊。
JAVA不也面临类似的疑问么？

得到一些也要失去一些。什么也替代不了你自己独立的、因地制宜的、具体问题具体分析的判断。

Allen的方法时新版本的吧,
那个版本开始的?

sql 2000删除时可以设置别名的delete a from table a where a.id = ?
安全起见的话还是需要加一个SQL处理的，毕竟函数　CASE这些也算基本查询了　但不同还是很大的
CRUD问题不大

最不爽的是这个。
http://www.iteye.com/topic/244
没想到hibernate性能这个差。
莫非hibernate3.1用了ejb?为什么速度这么慢？
如果这么慢的话，那对于压力比较大的业务，hibernate其实是不能用的。