使用Hibernate时数据库的设计问题

Hibernate作为一个ORM框架是比较火热的，虽然在性能上会有一定的下降，但是，其优越性是非常明显的，不仅仅是在设计模式方面，而且在数据库的适应性方面，因为语句使用 了HQL语句，使对象操作可以适用于绝大多数主流的数据库，一个很好的例子，如果有这方面的需求，就是如果更换数据库的话，仅仅修改hibernate.cfg.xml文件就可以了，当时我是这么想的，当时在一般意义上的数据库设计修改也是完全可以实现的，但是，问题是，在实际的项目开发中，这种理想化的解决方案是远远错误的，或者说是不现实的，当我更改了配置文件，连接等必然是可以的，但是，映射文件呢？也是要重新修改映射文件的，另一方面数据库的设计在代码重构和项目的运行效率方面是影响非常大的，所有这里仅仅说一下数据库的设计对hibernate数据库的影响。

1：建立数据表必须要有主键，而且建议要有自增策略，这里数据库之间的方案是不同的，如mysql数据库使用auto_increment就可以了，Oracle则需要使用特有的序列，而恶心的sql server使用identity属性设置，必然无论怎么设计表，在hibernate映射文件，关于表的自增策略，是必然要修改的，所以只修改配置文件这种说法是不对的，当然，你可以考虑重新自动映射。

2：数据表的设计不建议有外键关系，不仅仅是对hibernate数据库，大多数成熟的数据库设计都是没有外键的，一开始我是不理解的，但是后来想明白了，外键约束在一定程度上会降低数据库的执行效率，而且，如果有了外键，一定程度上也可以说在数据库设计中牵扯到了业务关系，表之间的耦合度大大增加了，更为严重的是，在hibernate映射中，外键关系被映射成了set集合的成员变量，数据的查询操作，通过对象的操作来执行，必然硬外外键关系的存在全部获取到，而且会发送更多的sql语句，尽管有懒加载机制，但是这种方案并不是很理想。

3：不要有存储过程，触发器等有关业务的操作在数据库设计，一开始觉得这样可以减少业务层的代码量，但是后来发现，这样做的后果几乎完全使hibernate失去了存在的意义，业务层的代码绝对不能再数据库色设计，这是非常失败的设计，一方面加大数据库的压力，另一方面极不利于数据库的修改和迁移等，很得不偿失。

以上仅仅是自己的一点见解。