什么时候才值得在Doctrine2中保持反向关系？

Posted 2023-02-27

在学说手册中，在 尽可能地限制关系它给出的建议是 "消除非必要的关联 "和 "尽可能避免双向关联"。我不明白什么标准会让一个关联成为 "必要的"。

我之所以这么说，是因为你似乎经常想从一到多的关联中的 "一 "方面去做，而不是从 "多 "方面去做。例如，我想得到一个用户的所有活跃的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是不可能的，反正水化可能也不行。这就是为什么我不明白为什么增加逆向关系是个坏主意。

答案

使用Doctrine，我只在需要的时候定义关系。这意味着所有定义的关系都会在代码库中实际使用。

对于有一个大型团队在项目的不同领域工作的项目，并不是每个人都会习惯使用Doctrine，它的当前配置，以及急于加载关系。如果你在不是必要的地方定义了双向关系，而且可能没有意义，就有可能导致额外的数据查询，这些数据。

1. 可能不会被使用
2. 可曾被选中

只定义必要的关系将使您能够更好地控制您和您的团队如何遍历您的数据，并减少额外的或过于庞大的查询。

更新日期：22082011

所谓的本质关系，我指的是你使用的关系。定义一个你不会用的关系是没有意义的。比如说

• \Entity\Post 有一个定义的关系到两个 \Entity\User 和 \Entity\Comment
  • 使用 $post->user 获得作者
  • 使用 $post->comments 以获得所有评论
• \Entity\User 有一个定义的关系，既 \Entity\Post 和 \Entity\Comment
  • 使用 $user->posts 以获取所有用户的帖子
  • 使用 $user->comments 以获取所有用户评论
• \Entity\Comment 只与 \Entity\User
  • 使用 $comment->user 获得作者
  • 不能使用 $comment->post 因为我没有检索到它的所属职位。在我的申请中

我不会把它们看作是 "反向 "关系。把它们看成 "双向"，如果在两个方向上使用数据是有意义的。如果它没有意义，或者你不会那样使用数据，就不要定义它。

我希望这有意义

另一答案

我觉得这是一个很好的问题，很期待别人的回答。

一般来说，我把你在down中引用的建议解释为以下经验法则。

如果我不需要在我的实体中访问（反）关联，那么我通常会使它成为单向的。 在你的用户和（未完成的）调用的例子中，我可能会保持它的单向性，并让一些服务类或存储库为我需要获得最近有未完成的调用的所有用户的列表的奇特情况下，处理好自定义DQL。 这种情况我认为是特殊的--大多数时候，我只是对某个用户的调用感兴趣，所以单向关系是可行的（至少在我有这么多记录，我觉得有必要优化之前）。