对象关系映射的缺点

Question

我是ORM的粉丝 - 对象关系映射,过去一年半我一直在使用Rails.在此之前,我使用JDBC编写原始查询,并使数据库通过存储过程完成繁重的工作.使用ORM,我最初很乐意做类似的事情coach.manager,manager.coaches而且非常简单易读.

但是随着时间的推移,有许多协会在不断涌现,我最终还是在a.b.c.d幕后向所有方向发射查询.使用rails和ruby,垃圾收集器变得疯狂,并且花费了大量时间来加载一个非常复杂的页面,其中包含相对较少的数据.我必须通过一个简单的存储过程替换这个ORM样式代码,我看到的结果是巨大的.现在需要50秒才能加载的页面只需2秒钟.

有了这个巨大的差异,我应该继续使用ORM吗？很明显,与原始查询相比,它具有严重的开销.

一般来说,使用像Hibernate,ActiveRecord这样的ORM框架有哪些常见的缺陷？

Answer 1

ORM只是一种工具.如果你没有正确使用它,你会得到不好的结果.

没有什么能阻止您使用专用的HQL /条件查询(使用提取连接或投影)来返回页面必须在尽可能少的查询中显示的信息.这将与专用SQL查询或多或少同时进行.

但是,当然,如果您只是通过ID获取所有内容并浏览对象而未意识到它生成了多少查询,则会导致加载时间过长.关键是要确切了解ORM在场景背后的作用,并确定它是否合适或是否必须采用其他策略.

Answer 2

我想你已经确定了与ORM软件相关的主要权衡.每次添加一个新的抽象层,试图提供你曾经手工完成的事物的通用实现时,性能/效率会有所下降.

正如您所指出的那样,遍历多个关系(例如a.b.c.d效率低下)可能效率低下,因为大多数ORM软件都会对每个人进行独立的数据库查询..但我不确定这意味着你应该完全消除ORM.大多数ORM解决方案(或者至少肯定是Hibernate)允许您指定自定义查询,您可以在单个数据库操作中准确地返回所需的内容.这应该与专用SQL一样快.

真正的问题是要了解ORM层在幕后如何工作,并意识到虽然类似的东西a.b.c.d很容易编写,但是它导致ORM层在评估时所做的事情并非如此.作为一般规则,我总是采用最简单的方法开始,然后在有意义的区域编写优化查询/很明显简单方法无法扩展.