Request
在我的业务领域中,两个实体Action
处于一对一的关联中,如下所示:
我通过休眠来坚持它们。问题是,如果我将它们保存在两个表中,我将不得不面对 1+n 的问题。如果我将它们保存在一个表中(通过从同一个超类继承它们)休眠使用鉴别器,以便它们最终出现在表的两个不同行中,这意味着相同的 1+n 问题。
我是否可以将这两个实体的关联实例保存在具有相同 ID 的表的同一行的不同列中?还是有更好的主意来处理这种情况?
Request
在我的业务领域中,两个实体Action
处于一对一的关联中,如下所示:
我通过休眠来坚持它们。问题是,如果我将它们保存在两个表中,我将不得不面对 1+n 的问题。如果我将它们保存在一个表中(通过从同一个超类继承它们)休眠使用鉴别器,以便它们最终出现在表的两个不同行中,这意味着相同的 1+n 问题。
我是否可以将这两个实体的关联实例保存在具有相同 ID 的表的同一行的不同列中?还是有更好的主意来处理这种情况?
不,不应使用两个实例来表示同一行,因为当您删除其中一个实体时会发生什么?为什么不只使用一个实体和一个可嵌入的?假设 Action 没有 Request 就不能存在,它将是可嵌入的并且存在于 Request 表中。
如果 Request 和 Action 都是Entity,我更喜欢一对一的解决方案。我使用条件查询并指定获取模式来加入以避免 n+1 问题。
Criteria c = session.createCriteria(Request .class);
c.setFetchMode("action", FetchMode.JOIN)
return c.list();
但是,如果您的 Request 与多个Entity关联,则必须开发许多临时查询方法,这有点麻烦。
public interface RequestRepository {
List<Request> findWithAction(Criteria criteria);
List<Request> findWithAnotherEntity(Criteria criteria);
}
如果 Action 只是一个ValueObject,我使用 @Embeded ,因此它们可以存储在一个表中。
你有没有考虑过懒惰的行动。这将避免在您真正需要之前获取 Action。例如
@OneToOne(fetch = FetchType.LAZY, optional = true)