Rails ORM是否限制执行聚合的能力？
我担心Rails是否可以处理财务应用程序所需的复杂聚合类型，特别是ORM是否可以有效地处理这些聚合。 在我考虑使用它的财务应用程序中，需要对各种方式汇总的详细财务数据进行大量报告。 如果没有Rails ORM的支持，我需要编写直接SQL。 但是我担心一旦我开始这个，Rails的其他部分也可能无法正常工作，因此我最终可能会使用Rails作为其路由，而其他很少。 这是一个有效的问题还是我不必要地担心？
ActiveRecord的限制是我在科学环境中使用Rails时遇到问题的原因之一。 您可能想要查看替代Ruby ORM，这样可以更轻松地使用旧数据库：
- 续集
- 的DataMapper
最终，虽然ORM的设计让你远离SQL，但它们可能都不适合。
这个问题说明了一个相当广泛讨论的RoR问题 – 它对困难的数据库映射要求相对不适。 （它确实是存在困难的ActiveRecord模式。）它喜欢将复杂的查询分解为更接近AR模型的更简单的查询，您可能已经知道这是一种相对较轻的表格抽象，基于例如一个简单的关系对多种类型的断言。
所以，如果你自己接受SQL职责，那么我会说你会更舒服，然后让RoR处理非持久性部分。
这不是限于RoR的窘境。 大多数对象关系建模工具都提出了相同的问题。
（脚注：我几乎使用了缩写ORM，但是另外还有一个ORM巧妙地处理了这些类型的概念数据库设计和abstration问题：对象角色建模。）
Rails可能不适合此应用程序。 或者您可以考虑对数据库中的视图使用ActiveRecord。 在您的视图中聚合您的数据，然后使用’rails_sql_views’gem，您可以像普通模型一样对待它们。 （我从来没有用过这个，所以我不知道这在实践中有多好。）
链接： rails_sql_views
编辑：在进一步检查时，您可能甚至不需要任何gem或任何其他特殊设置来简单地查询视图。
我喜欢活跃记录的原因是它允许你浏览抽象。 我还没遇到过AR无法处理的情况。 我确信可能会有一些非常深奥的例子，但更好的问题是举例说明你想要做的查询类型，并让别人告诉你如何在AR中做到这一点。