何时使用ORM（Sequel、Datamapper、AR等）与纯SQL进行查询

我的一位同事目前正在设计下面这样的SQL查询来生成报表，这些报表通过外部数据查询显示在excel文件中。 目前，只需要数据库上的报告过程（无CRUD操作）

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

尽管在显示数据方面有明显的优势，但在学习使用类似ORM的Sequel或Datamapper方面，他有哪些优势

他正在编写的SQL查询显然相当复杂，而且对于SQL来说是比较新的，他经常抱怨这非常耗时和混乱。

---

是否可以使用ORM编写极其复杂的查询？如果是这样的话，哪一个最合适（我听说Sequel对遗留dbs很好）？在进行复杂的数据库查询时，学习ruby和使用ORM与坚持使用普通SQL相比有什么优势？

ORM代表对象关系映射-但是查看查询，您的朋友似乎想要一个非常具体的总和和其他项表。。。我没有使用Ruby的Sequel，但我使用了Hibernate和Python的SQLAlchemy（用于Django/Turbogears），虽然您可以进行此类查询，但我不认为这是它们的优势所在

ORM的力量来自于能够找到Foo->Bar对象关系，比如说你希望Foo字段的所有Bar对象都大于X。。。诸如此类的事情。因此，我不会将ORM归类为“好”的解决方案，尽管我会转向Ruby这样的真正编程语言，并通过它而不是Excel来执行SQL。。。这本身就是一场胜利

---

只要我的2美分。

如果您手工编写查询，您就有机会对其进行优化。当我查看该查询时，我看到了一些可能的优化（例如“%san fransisco%”之类的E.ICGROUPNAME或“%bordeaux%”之类的E.ICGROUPNAME不会使用索引=表扫描）

使用或映射器（本机对象/表）进行报告时，您无法或几乎无法控制生成的SQL查询

---

但是：您可以将该查询放在视图或存储过程中，并使用或映射器映射该视图/过程。您可以优化查询并使用应用程序框架的所有功能。

在这种情况下，我可能会手工编写它们或使用视图（如果您使用的数据库支持视图）

除非您处理对象，否则不需要ORM。听起来您的朋友只需要生成报告，在这种情况下，纯SQL只要知道自己在做什么就可以了（例如，避免SQL注入问题）

---

ORM代表“对象关系映射”。如果你没有“O”（对象），那么它可能不适合你的应用程序。ORMs真正的亮点在于将对象持久化到数据库并从数据库中加载它们。

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

虽然我确实认为有一天我们会有一个DSL，它提供SQL的强大和简洁，但到目前为止，我所看到的一切都要求您为复杂的查询编写比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

类用户
包含数据映射器：：资源
属性：id，序列号
属性：name，String，：length=>1..100，：required=>true
属性：年龄，整数，：min=>1，：max=>130
def self.some_complex_查询
repository.adapter.selectORM在您有对象（业务对象）时使用。因此，我假设您有一个应用程序，您可以使用它创建和管理最终保存到数据库中的业务对象。如果你有，那么你几乎肯定得到了一些关系的表示，可能还有很多你将在报告中使用的计算。使用SQL直接访问数据库以获取报告的问题在于可维护性。
您通常会投入大量精力来确保业务对象隐藏其数据库的任何细节。您可以在业务对象中实现业务规则并进行通用计算。为团队的所有成员建立一种通用语言，等等。然后使用ORM映射到数据库，并使用或NHibernate或类似的东西来实现这一点。这一切都很棒。我们是以可维护性的名义这样做的，这很好。您可以迁移应用程序，更改设计等

现在，您可以编写SQL来随时间运行报表—您有数百个报表。首先，它们经常复制您在BusinessObjects中已有的逻辑（通常没有任何测试）更糟糕的是，Bham Damb抱歉的可维护性现在被塞满了忘记将该字段从一个表移动到另一个表忘记将该表拆分为两个更改该关系等您有许多报告将意外中断

通过域对象/业务对象进行查询的问题只是性能问题之一

总之，如果您使用的是域驱动设计或业务对象概念，请尝试将其用于报告。（出于性能原因，您可能会使用SQL或存储过程直接从DB运行，但请尝试使用您的Bu限制这些