何时使用ORM（Sequel，Datamapper，AR等）与纯SQL进行查询
我的一位同事正在设计像下面这样的SQL查询来生成报告，这些报告通过外部数据查询显示在excel文件中。 目前，只需要DB上的报告流程（无CRUD操作）。
我试图说服他，为了能够在rails / sinatra应用程序中显示数据，最好使用ruby ORM。
尽管显示数据有明显的优势，但学习使用像Sequel或Datamapper这样的ORM有什么好处？
他正在编写的SQL查询显然非常复杂，并且相对于SQL来说相对陌生，他经常抱怨说它非常耗时且令人困惑。 是否可以使用ORM编写极其复杂的查询？ 如果是这样，哪个是最适合的（我听说续集对传统dbs有好处）？ 在进行复杂的数据库查询时，学习ruby和使用ORM与坚持纯SQL相比，有哪些优势？
我是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上下文中查看。 只是想澄清任何可能的混淆。
如果您手动编写查询，您有机会优化它们。 当我查看该查询时，我看到了一些优化潜力（E.ICGROUPNAME LIKE'％san-fransisco％'或E.ICGROUPNAME LIKE'％bordeaux％'将不会使用索引=表扫描）。
当使用OR映射器（本地对象/表）进行报告时，您无法或很少控制生成的SQL查询。
但是：您可以将该查询放入视图或存储过程中，并使用OR映射器映射该视图/ Proc。 您可以优化您的查询，并且可以使用应用程序框架的所有功能。
除非你处理对象，否则不需要ORM。 这听起来像你的朋友只需要生成报告，在这种情况下，只要他知道自己在做什么（例如避免SQL注入问题），纯SQL就可以。
ORM代表“对象关系映射”。 如果你没有“O”（对象），那么它可能不适合你的应用程序。 ORM真正发光的地方在于持久化对象到数据库并从数据库加载它们。
链接地址: http://www.djcxy.com/p/95965.html上一篇: When to use an ORM (Sequel, Datamapper, AR, etc.) vs. pure SQL for querying