Rails ORM 是否限制执行聚合的能力？
我担心 Rails 是否可以处理金融应用程序所需的复杂聚合类型，特别是 ORM 是否可以有效地处理这些类型。 在我正在考虑使用它的财务应用程序中，需要对以各种方式汇总的详细财务数据进行大量报告。 如果没有 Rails ORM 的支持，我需要直接编写 SQL。 但我担心一旦我开始这样做，Rails 的其他部分可能无法正常工作，因此我最终可能主要使用 Rails 来处理其路线，而很少使用其他部分。 这是一个合理的担忧还是我不必要地担心？
I am concerned whether Rails can handle the types of complex aggregations that are needed for a financial application and particularly whether the ORM can handle these effectively.
In a financial application that I am thinking of using this for, there is a need to do lots of reporting of detailed financial data, aggregated in various ways. Without support in the Rails ORM, I would need to write direct SQL. But I am concerned that once I start this, other parts of Rails may not work as well and that as a result I may end up mostly using Rails for its routes and very little else. Is this a valid concern or am I worrying needlessly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
ActiveRecord 的局限性是我在科学环境中使用 Rails 时遇到困难的原因之一。 您可能想查看替代的 Ruby ORM，它可以更轻松地使用旧数据库：
最终，ORM 的设计会让您远离 SQL，因此有可能他们都不适合。
Limitations of ActiveRecord are one of the reasons I had trouble using Rails in a scientific environment. You might want to check out alternative Ruby ORM's that make it a bit easier to work with a legacy database:
Ultimately though ORM's by design take you away from SQL so it's possible that none of them are a good fit.
这个问题说明了一个被广泛讨论的 RoR 问题 - 它相对不适于困难的数据库映射要求。 （这实际上是 ActiveRecord 模式的困难所在。）它喜欢将复杂的查询分解为更适合 AR 模型的更简单的查询，您可能已经知道这是对表的相对较轻的抽象，具有基于例如一个的简单关系-对多类型断言。
所以我想说，如果你自己接受 SQL 职责，然后让 RoR 处理非持久性部分，你会更舒服。
这不只是 RoR 的困境。 大多数对象关系建模工具都会提出相同的问题。
（脚注：我几乎使用了缩写 ORM，但还有另一个 ORM 恰好可以很好地专门处理这些类型的概念数据库设计和抽象问题：对象角色建模。）
This question illustrates a RoR issue that's pretty widely discussed - its relative discomfort with difficult database mapping requirements. (it's really the ActiveRecord pattern where the difficulties lie.) It likes to decompose complex queries into simpler ones that fit more closely to the AR model, which you probably already know is a relatively light abstraction over tables, with simple relationships based on e.g. one-to-many type assertions.
So I'd say you'll be more comfortable if you accept SQL duty yourself, and then let RoR handle the non-persistence parts.
This isn't a quandary limited to RoR. Most any Object-Relational Modeling tool presents the same questions.
(Footnote: I almost used the abbreviation ORM, but there's another ORM that coincidentally handles specifically these types of conceptual database design and abstration issues quite nicely: Object Role Modeling.)
Rails 可能不是该应用程序的合适平台。 或者您可以考虑对数据库中的视图使用 ActiveRecord。 在视图中聚合数据，然后使用“rails_sql_views”gem，您可以像普通模型一样对待它们。 （我从未使用过这个，所以我不知道它在实践中效果如何。）
链接：rails_sql_views< /a>
编辑： 经过进一步检查，您甚至可能不需要任何 gem 或任何其他特殊设置来简单地查询视图。
It's possible that Rails is not an appropriate platform for this application. OR you could consider using ActiveRecord against views in your database. Aggregate your data in your views, then using the 'rails_sql_views' gem you can treat them like ordinary models. (I have never used this, so I don't know how well this works in practice.)
Link: rails_sql_views
Edit: On further inspection, you might not even need any that gem, or any other special setup to simply query against views.
我喜欢活动记录的原因是它可以让你深入了解抽象。 我还没有遇到过 AR 无法处理的情况。 我确信可能会有一些极其深奥的示例，但更好的问题是给出您想要执行的查询类型的示例，并让某人向您展示如何在 AR 中执行此操作。
The reason I like active record is that it allows you to poke through the abstraction. I have yet to run into a situation I couldn't handle with AR. I'm sure there may be some extremely esoteric examples, but a better question would be to give an example of the type of query you want to do and let someone show you how to do it in AR.