Hibernate和ibatis(Mybatis) 选型参考

iBATIS Database Layer / Discussion / CLOSED - Users: vs. Hibernate
https://sourceforge.net/p/ibatisdb/discussion/206693/thread/ada39fb2/

Clinton Begin - 2003-08-08

就功能而言，我不知道可以轻松地对它们进行比较，因为产品确实属于不同的类别。一般的经验法则是：如果您正在启动一个新项目，并且完全控制了对象模型和数据库设计，那么Hibernate是O / R工具的不错选择。

但是，如果您正在访问任何第三方数据库（例如，供应商提供的数据库），或者您正在使用旧数据库，甚至只是设计不佳的数据库，那么O / R映射器可能无法处理这种情况。那是一个SQL Mapper派上用场的地方。使用SQL Mapper，对象模型和数据模型之间的映射没有任何限制-即使两者之间的设计不良（在现实世界中经常发生-都不要忘记您可能拥有的辅助数据库）访问...）。

 

没有人/匿名 - 2003-11-18

我在这场辩论中走来走去，并根据一些成功的项目提出了一些建议。

我们团队中有两种不同类型的开发人员。那些来自编写C / RPG的程序世界，以及那些具有Smalltalk / Java背景的人。我们的某些应用程序使用巨大的Oracle和DB2数据库，而其他应用程序使用较小的数据库。这些应用程序大多数使用Struts。

具有程序背景的人员倾向于与iBatis更好地结合，并以优化查询语句和缓存为荣。它们的应用程序化程度很高，并假定时钟周期很昂贵。我的意见是，由于数据库结构更改时许多SQL语句也会更改，因此它们的应用程序灵活性较差。

那些以面向对象的背景开始的人在Hibernate中可以更好地工作。它们的应用程序性较低，但要花费较长时间才能摆脱困境。预先花更多的时间定义数据库关系。对于新开发，当完成此阶段并且将来的数据库更改进行得更快时，应用程序更接近完成。对于旧数据库，此阶段可能会拖延，并且对象模型永远不是您想要的。

就缓存而言，Hibernate较少考虑，并且具有可配置的缓存，但是iBatis偏向查询优化人群。Hibernate的危险在于您过于频繁地丢弃会话并开始崩溃，而iBatis的危险在于开发人员认为他的查询过于重要。我根本不会缓存，而是使用性能分析来确定应该在哪里分配资源。

总的来说，我的观察是，在大型综合性旧数据库中查询时，iBatis处于最佳状态。在现代数据库上构建事务（原始）应用程序时，Hibernate处于最佳状态。如果将iBatis用于查询，将Hibernate用于事务性应用程序，则它们可以很好地共存。我会将iBatis推到旧数据库的事务处理方面，并将Hibernate推到新数据库的本机查询方面。

 

 

hibernate和ibatis的比较_iBATIS,Hibernate,SQL_简约时尚，突破自我-CSDN博客
https://blog.csdn.net/chenqian513/article/details/83354368

hibernate和ibatis的区别 - jmStatham - 博客园
https://www.cnblogs.com/jianglong-liang/p/3816677.html

 

数据库设计正规化的五大范式

数据库设计正规化的五大范式_数据结构,企业应用,SQL_简约时尚，突破自我-CSDN博客
https://blog.csdn.net/chenqian513/article/details/83287560

 

11 important database designing rules

11 important database designing rules which I follow - CodeProject
https://www.codeproject.com/articles/359654/11-important-database-designing-rules-which-i-fo-2