从项目的角度看Hibenate的不足，项目是否要用Hibernate，请慎重。

最近接触Hibernate,作了个项目，感到一些无奈。当你的项目要使用Hibernate时请考虑一下问题：

1：学习不足。     公司小，没有什么相关的技术培训，Hibernate全靠自己去网上查资料。那么在这种背景下做出来的项目，请问谁对它有信心？谁能保证这样的项目能一定成功？所以Hibernate只是适合学习，或者极小项目的应用。

2：数据库设计。 原来的数据库设计方式不行了，如果你的项目要用Hibernate，那么很遗憾，你以前在关系数据库下的设计方式可能要改了，原先你可能是业务逻辑分析设计数据库，然后再去编码实现，现在，你必须先考虑如何能让你的编码能顺利进行下去，然后再设计你的数据库，否则，即使你的数据库设计的再好，用Hibernate实现起来可能会困难重重，那就使你的设计大打折扣。所以，使用Hibernate的成本要增加了。小心！

3：Hibernate在表有多个主键的时候，性能很低，要特别处理，如果你的数据库中有很多表都有多个主键，嗯，还是考虑考虑别的吧！

4：项目风险。如果你的项目成员在项目进行中会有变更，请慎重。

5：业务逻辑很复杂，经常有复杂的复合查询，出于性能问题，在Hibernate中可能需要用原生SQL，那么一会儿HQL，一会儿SQL，会让人迷失方向。还不如不用HIbernate来的安全！

6：如果你的项目组成员是一些技术狂人，你的项目不是很重要的项目，时间不是很紧，比如公司一个产品项目，建议你用Hibernate，不管成功与失败，做一个这类的项目，以后再决定是否使用Hibernate时好有个判断的依据。反正代价也不大。反之，如果你的项目成员五花八门，高低不一，又没有什么精通Hibernate的高手，或者项目很重要，或者人员变动比较大，时间比较紧，还是不要用吧。

7：那些仅仅是为了使用Hibernate的封装特性少写SQL，为了减少代码量，缩短工期的，最好不要用！这样做纯粹是表面上捡了芝麻，背后却把西瓜给丢了。有很多工具可以帮助你完成上述工作，而不会给你的系统带来一大堆限制。

8：Hibernate是个不成熟的面向对象的数据库工作模型，在关系数据库上模拟对象数据库，就好比在windows系统下使用虚拟机模拟另外的系统一样，虽然方便，但是只是看看就好，不要指望它能真正帮你做事。