何时使用ORM(续集,数据映射器,AR等)与纯SQL进行查询

Question

我的一位同事目前正在设计类似下面的SQL查询来生成报告,这些报告通过外部数据查询显示在excel文件中.目前,只需要DB上的报告流程(无CRUD操作).

我试图说服他最好使用ruby ORM以便能够在rails/sinatra应用程序中显示数据.

尽管在显示数据方面有明显的优势,但他在学习使用像Sequel或Datamapper这样的ORM方面有什么优势呢？

他正在编写的SQL查询显然非常复杂,并且对于SQL来说相对较新,他经常抱怨它非常耗时且令人困惑.是否可以使用ORM编写极其复​​杂的查询？如果是这样,哪个是最合适的(我听说续集对遗留dbs有好处)？在制作复杂的数据库查询时,学习ruby和使用ORM与坚持使用纯SQL有什么好处？

Answer 1

我是DataMapper维护者,我认为对于复杂的报告,您应该使用SQL.

虽然我确实认为有一天我们会有一个提供SQL的强大功能和简洁性的DSL,但到目前为止我所看到的一切都要求你为复杂的查询编写比SQL更多的Ruby代码.我宁愿维护一个5行SQL查询而不是10-15行Ruby代码来描述相同的复杂操作.

请注意我说复杂..如果你有简单的东西,请使用ORM的内置查找程序.但是,我相信有一条线可以跨越SQL变得更简单.现在,大多数应用程序不只是报告.你可能有很多CRUD类型的操作,对于这些操作来说,ORM是非常适合的,并且比手工执行这些操作要好得多.

ORM通常会提供的一件事是应用程序逻辑的某种组织.您可以根据每个模型在同一文件中对代码进行分组.我通常会在那里放置复杂的SQL查询,而不是将其嵌入控制器中,例如:

class User
  include DataMapper::Resource

  property :id,   Serial
  property :name, String,  :length => 1..100, :required => true
  property :age,  Integer, :min => 1, :max => 130

  def self.some_complex_query
    repository.adapter.select <<-SQL
      SELECT ...
        FROM ...
       WHERE ...
       ... more complex stuff here ...
    SQL
  end
end

然后我可以使用生成报告User.some_complex_query.如果要进一步清理此代码,还可以将SQL查询推送到视图中.

编辑:通过上面句子中的"视图"我的意思是RDBMS视图,而不是在MVC上下文中查看.只是想澄清任何可能的混乱.

Answer 2

如果您手动编写查询,则有机会对其进行优化.当我查看该查询时,我发现了一些优化的可能性(E.ICGROUPNAME LIKE'%san-fransisco%'或E.ICGROUPNAME LIKE'%bordeaux%'不会使用索引=表扫描).

使用OR Mapper(本机对象/表)进行报告时,您无法或几乎无法控制生成的SQL查询.

但是:您可以将该查询放在View或Stored Procedure中,并使用OR Mapper映射View/Proc.您可以优化查询,并可以使用应用程序框架的所有功能.

Answer 3

除非您正在处理对象,否则不需要ORM.听起来你的朋友只需要生成报告,在这种情况下,只要知道他正在做什么(例如避免SQL注入问题),纯SQL就可以了.

ORM代表"对象关系映射".如果你没有"O"(对象),那么它可能不适合你的应用程序.ORM真正发挥作用的是将对象持久化到数据库并从数据库加载它们.