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

Question

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

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

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

他正在编写的 SQL 查询显然非常复杂，而且由于对 SQL 相对较新，他经常抱怨它非常耗时且令人困惑。 是否可以使用 ORM 编写极其复​​杂的查询？如果是这样，哪个是最合适的（我听说 Sequel 对于遗留数据库有好处）？在进行复杂的数据库查询时，学习 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 映射器（本机对象/表）进行报告时，您无法或很少控制生成的 SQL 查询。

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

Answer 3

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

ORM 代表“对象关系映射”。如果您没有“O”（对象），那么它可能不太适合您的应用程序。 ORM 真正出色的地方在于将对象持久保存到数据库并从数据库加载它们。

Answer 4

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

ORM 的强大之处在于能够找到 Foo->Bar 对象关系，假设您希望 Foo 字段的所有 Bar 对象都大于 X...之类的事情。因此，我不会将 ORM 归类为“好的”解决方案，尽管转向像 Ruby 这样的真正编程语言并通过它而不是 Excel 执行 SQL...这本身就是一个胜利。

只是我的2分钱。

Answer 5

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

Answer 6

当您有对象（业务对象）时，就会使用 ORM。因此，我假设您有一个应用程序，用于创建和管理最终保存到数据库中的业务对象。如果您已经了解了，那么您几乎肯定已经获得了一些关系的表示，并且可能还获得了您将在报告中使用的许多计算。使用 SQL 直接访问数据库以获取报告的问题在于可维护性。
您通常会花费大量精力来确保您的业务对象隐藏其数据库的任何详细信息。您可以在业务对象中实施业务规则并进行常见计算。为团队的所有成员建立一种通用语言等。然后，您使用 ORM 映射到数据库并使用 Habanero< /a> 或 NHibernate 或类似的东西来做到这一点。这一切都很棒。我们以可维护性的名义做这一切，这很棒。您可以迁移您的应用程序、更改您的设计等。

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

查询域对象/业务对象的问题只是性能问题之一。

总之，如果您正在使用领域驱动设计或业务对象概念，请尝试将它们用于报告。 （出于性能原因，您可能会使用 SQL 或存储过程直接从数据库运行，但请尝试先限制这些使用您的业务对象，然后再使用 SQL）。
当然，另一种选择是使用单独的报告数据库（如某些 BI 概念），因此从事务数据库到报告数据库的映射位于一个位置，并且在您想要更改设计的情况下可以轻松更改。

领域对象（业务对象）和 ORM 拥有所有知识，允许您在使用领域术语时开始构建直接在数据库上运行的高性能查询。让我们希望这些能够继续发展到成为现实。

在此之前，如果您在应用程序中使用业务对象，那么当性能成为 SQL 的一个问题时，请尝试将它们用于报告。