hibernate作为一个数据库操作组件（也许这样称呼是错的），那么，我们使用hibernate，希望它是稳定的，简单的并且有效的为我们使用，那么，我们必须约束一些各方面的规范，当我们的规范成本远小于它所带来的价值，那么我想这是值的推荐的。
一、数据库设计
  1，所有的表设计建议有主键，对于hibernate来说，无主键的表可能就是把所有字段作为一个复合主键来使用，所有说有主键的表会使用在很多方面比较方便，建议尽量不使用复合主键，当复合主键作为外键对应时，mapping文件的配制及vo对像的书写会变的较复杂，（我一项提倡多一事不如少一事的观点）复合主键可以用代理主键代替，java生成的32位随机码uuid值的推荐。
   2，对于hibernate来说，在较大的系统中，数据库表繁多，那么对于hibernate的一些xml、vo、dao文件等，建议用自动生成工具，无论是开源的，还是自己开发的，因为程序出错的概率远比人小的多。那么对于自动生成工具，首先表的字段及表名应该遵守一些规则，具体可根据自身要求定义，结合java中类命名与属性命名进行对应。如表设计中很多情况下加下划线，而在类中不推荐这样做，那么mapping对应时表对应的类名可变为首字母大写、下划线去除、下划线之后字母大写等。
  3，如果是根据数据库设计文件来定义hibernate的这些文件，那么一些注释信息都可以写入这些文件中（如erwin生成的xml文件）。
二、hibernate的使用
   在项目进行中，要清楚自己要用它来干什么，对于oltp系统来说，hibernate主要是用于��入、删除、更新，这些操作基本上都是我们想要的，面向对象的这些操作的确比较方便，我们所希望的是hibernate解决系统中60-70%的数据操作就够了，对于一些复杂的查询，建议用sql吧，hql感觉还是不很方便，毕竟一个程序员，sql书写是应该要掌握的，这无论在什么语言都可能用到，而hql不是必须的。而对于一些简单的查询操作，应该使数据库操作接口定义此种方法，selectByPk,selectByVo等，而这些方法的实现就写入dao吧。
   对于hibernate中的一些对应，我始终觉得，多对多，多对一，一对多，一对一都可以综合成一对多，一对一的关系，说白了用的多的就是找出A表中此字段作为B对应主键的一条记录，而相对B来说就是找出A表中此主键对应B表的一个集合，那么，如果是这样弄的话，简单了很多，mapping文件就可以直接写这两种了，这两种方法感觉是必须的，但如果想省事，那么mapping文件我们都可以不定义，真接把这方法写入dao中，而这两种方法也比较简单，其实就是调用前面所说的B类的selectByPk,B类selectByVo，（当然，这样的话就相当于lazy="true"，这个延迟加栽感觉在项目中应该是false的情况比较少，看它很多情况下并不一定要看它的孩子啊-_- ），在能满足技术的要求下，一切从简的方法有利于项目的稳定、加快项目的开发进度。   
题外话：hibernate作为一种开源的组件资源,它的成功是有目共瞩的，我想hibernate的初衷是为了解决关系数据库与在向对象操作的一种协调，及数据库与对象之间的一种持久、统一机制。但随着它的发展，必然出来很多新的问题，就像以前版本没有批量操作，而在3.0之后加入，包括HQL的扩展，为了解决各种各样的问题，它也会变的越来越膨大，但对于我们的项目来说，我们应该认识到， hibernate能解决我们多少问题，哪些是我们关心的，并不是hibernate所能解决的问题我们都要用到。我公司04年上的项目，用的hibernate是1.1，直到现在也还在用，但基本上也没有什么问题。
     我们解决问题时，不能只是想到hibernate怎么来处理这个问题，更多时间可能从其它方面解决会来的更快，如数据库的设计，利用其它方法，sql等，hibernate只是一个资源，对于一个项目来说，这个资源是大众化的，那么我们就应该只取我们关心的、有用的，我们甚至要考虑学习hibernate的成本，是不是应该项目的每个人都要完全掌握hibernate呢，人员流动情况下怎样保证项目的胜利进行，我们是否能够把hibernate作为一种公用的简易资源来让每程序员使用（程序员只要求知道一些相应接口及一些规范），这种模式在很多公司应该很早就是如此（我当时进公司，用了好几个月的java都不知道自己在用hibernate,还为天下操作数据库就是如此的对象操作，jdbc操作还是以后才知道）。
   好像也打了蛮多字，但感觉没谈到点上，毕竟参加工作时间不长，而且很久都没有写java了（很长时间在搞数据仓库），技术细节方面都不太好深入（技术不够，深入不了），
附上一个好久前写的一个自动生成的东西。
最后一句话：当版主不易啊，就为这点东西，一上午没了