sql - ActiveRelation 准备好迎接黄金时段了吗？

Question

我刚学rails。我非常喜欢 Rails。在几乎所有情况下，它都完全破坏了 Java 和相关的生产力解决方案——我对 Java 有十多年的经验，真的非常快……这说明了一些问题!如果 Rails 无法做到这一点，那么有一颗 gem 让我大吃一惊。

然后是主动关系。我真的很努力地使用它作为我的主要查询方法，但这是不行的。我发现一旦我开始构建需要 2 个连接的查询，我就会开始收到没有意义的奇怪错误消息……老实说，所有范围都很难推理。

虽然这种方法可能会使事情更具可读性，但我认为从大局的角度推理正在发生的事情的成本……以及编写查询的成本……可能无法收回成本。如果你真的很擅长sql...或者hql这样的语言...这种做事方式其实是一种生产力损失。至少对我来说是这样。

我可以忍受它，但我无法使嵌套连接起作用。例如，如果我有 A<->B<->C，并且 B 是一个也是多对多关系的模型，ActiveRelation 会提示其中一个外键的名称是错误的......即使它是实际上是正确的。我认为这是一个错误。所有使用作用域进行单一连接的查询都可以完美地工作......但是如果你将这些非常相同的作用域组合起来进行 2 个连接，它就会失败。我看不出有什么办法可以解决它。

我可以只做一个连接，然后让 ORM 为我做剩下的事情……但这将是一种性能浪费。对于一个大网站来说，这将以灾难告终。我正在编写一个庞大的系统，每个请求存储大量关系数据树。使用 ORM 遍历图形是一个太多的性能 killer ，我什至不会费心继续编写应用程序的其余部分。如果是这种情况，我可能不得不回到 Java。

最重要的是，我在网上找不到任何多重连接的例子。甚至文档也几乎没有提到连接和合并。

所以...准备好迎接黄金时段了吗？如何在 Rails 中进行真正复杂的 7-9 表连接？ Rails 不是为此而构建的吗？我之所以问这个，是因为如果 Rails 不能处理这种类型的查询，我将不得不停止使用它……并且相信我……这是一个巨大的、真正的耻辱……因为我绝对喜欢其他一切。我真的希望我错了，一切都很好。

Answer 1

说实话，我可以理解一点，但事实是我们大多数时候都不知道如何处理事情并感到沮丧。学习曲线陡峭的 Rails 就是一个很好的例子 :) 有一次我试图做一个左外连接，它看起来很乱，结果发现我可以用一种更简洁的方式来做。

Rails 实际上可以进行各种连接，一旦您学会了如何指导它(根据我的经验，这确实是一个挑战)。

我发现有时使用一点 Ruby 可以使过程更容易。一张小 map 可能就能挽救一切。

但是，当您不能做某事时，并不是因为 Rails 无法处理它，而是因为您还没有正确完成它的知识。 Rails 很难，有些东西看起来很不清楚，只是因为你一开始不知道。

关于 A、B、C 的事情，它应该可以正常工作。很有可能(如果不确定)您在命名 key 时做错了(您可以 100% 确定这不是 Rails 错误:)