对于复杂实体的双向多对多关联，添加/删除连接表关联的最有效方法是什么？

Question

为了清楚起见，我不是在问如何让事情运转起来，而是什么样的方法会有最好的性能。

我之所以如此关注性能，是因为我要处理两个非常复杂的层次实体。为了给你一点背景知识，该程序用于跟踪出勤情况，因此所讨论的两个实体是位置（人们参加的地方）和原因（如果人们可以参加以及为什么）。这两个实体处于双向多对多关系中，其中每个实体在数据库中有数千条记录，除了包含关联的映射表之外，彼此完全独立。一个人可以参加一个地点，可以有少到1个无限多的理由，也可以有少到1个无限多的地点。

即一个'人在安全组RED'的Reason用于授予对位置'Lab A'、'Lab B'和'Lab C'的访问权限，导致连接表包含3个条目，每个条目都与'人在安全组RED'作为关系的Reason方，并且每个实验室位置将其关联到每个实验室位置实体。相反，位置'Lab A'也可能包括其他Reasons，例如'安全组BLUE'和'训练事件X'，因此在连接表中会有这些Reasons的附加记录。

这两个实体本身都很复杂，并且有许多自身的级联关联。i、 e.Reason实体有一个自己要维护的三层级联关系结构，而位置实体有许多与其相关的其他关联，这些关联完全独立于Reason实体。我强调这一点是为了强调始终拉入所有实体关联只是为了更新联接表条目的性能影响问题。

大多数时候，当位置或原因被更新时，它将完全独立于它们之间的关联，所以我不想担心位置

如果可以的话，我想避免级联行为，因为我不希望对这些实体进行不相关的更改来触发复杂的级联保存。即当位置'X'发生变化时，当我当时没有更改与位置'X的原因相关的任何内容时，我不想引入它的许多原因及其所有三层级联依赖项。我也不想引入所有位置'X的原因s（及其依赖项）只是为了添加/删除位置中的条目

我想知道是否有方法瞄准位置

也就是说，当我去更改有关位置的其他详细信息时，我仍然希望获得与位置相关联的原因的基本详细信息，而不将该位置的保存操作级联到其原因s（因此每个原因的下游关联），反之亦然，当需要向这些实体的连接表添加或删除条目时，我不希望这些实体直接保存，因为那样我就不得不担心它们所有的其他数据和关联会被更新。

如果hibernate及其跟踪实体而不是其关联的性质不可能实现这种设置，那么这些实体的关联设置将具有最佳性能，因为每个实体已经有许多其他级联操作要处理，并且这些实体上的大多数操作根本不会触及它们之间的连接表，只有那些有针对性的添加/删除操作才特别需要更新位置和原因之间的连接表，而不需要更新其他内容。




Answer 1

首先，你几乎总是不想要真正的多对多关联。有时，您需要跟踪其他数据，如这些连接表的时间戳，此时您必须重写逻辑，因此我建议您始终尝试将连接表建模为具有两个多对一关联的实体，反之，则为一对多关联。连接表的实体有一个复合id，由多对一关联的id组成。

这使您能够通过执行持久/合并/删除或使用更新/删除DML查询来手动管理条目。这将表现得最好，唯一的“缺点”是你可能会提前做你可能不需要的工作，因为事实上这可能是一个真正的多对多，尽管我非常怀疑。