何时在Doctrine2中维持反向关系是否值得？

Question

在Doctrine手册中,尽可能在Constrain关系下,它给出了"消除非必要关联"和"尽可能避免双向关联"的建议.我不明白什么标准会使协会"必不可少".

我之所以这么说,是因为看起来你经常想要从一对多关系的一方而不是多方方面.例如,我想获取所有用户的活动PhoneNumbers,而不是获取所有活动的PhoneNumbers及其关联的用户.当您必须遍历多个一对多关系时,这变得更加重要,例如,如果您希望在过去两天内看到所有具有MissedCall的用户(MissedCall-> PhoneNumber-> User).

这是简单情况下反向关联的外观:

SELECT * FROM User u
LEFT JOIN u.PhoneNumbers p WITH p.active

如果有一种方法可以在DQL中以相​​反的方向跨越给定关系,那将会更加明智,如下面的原始SQL:

SELECT * FROM User u
LEFT JOIN PhoneNumber p ON p.User_id = u.id AND p.active

有人可以解释为什么他们提出这个建议,在什么情况下值得忽略？

- 编辑 -

如果有缓解因素或其他解决方法,请给我简单的示例代码或链接.

当没有定义逆时,我没有看到任何方法来遍历关系的逆,所以我将假设构建自定义DQL 实际上不是一个解决方案 - 有一些与SQL 无关的连接是不可能的无论如何,DQL和水合作用可能都行不通.这就是为什么我不明白为什么添加反向关系是一个坏主意.

Answer 1

我认为这是一个很好的问题，我期待其他人的答案。

一般来说，我将您在下面引用的建议解释为以下经验法则：

如果我不需要访问实体内部的（反向）关联，那么我通常将其设为单向。在您的用户和（错过的）呼叫示例中，我可能会保持单向，并让某些服务类或存储库处理将自定义 DQL 放在一起，以应对当我需要获取最近错过呼叫的所有用户的列表时出现的奇怪情况。这是我认为例外的情况 - 大多数时候，我只对特定用户的呼叫感兴趣，因此单向关系有效（至少在我有这么多记录以至于我觉得需要优化之前） 。