如何在 Hibernate 的同一张表上建模 ManyToOne 和 ManyToMany 关系？

Question

我想在表之间创建如下关系

表格 -

• 所有者 - 所有者表包含有关所有者的详细信息。
• DietPlans - DietPlans 表包含所有者可以创建的所有饮食计划。所有者可以创建n 数量的饮食计划，但每个饮食计划都属于一个所有者。因此，它是 1 到 n 的关系或一对多关系。
• 客户 - 客户基本上是一个消费饮食计划的实体。换句话说，我希望客户订阅已经存在的饮食计划。因此，我的理解是，客户订阅饮食计划将是多对一的关系。 n 客户数量可以订阅n 饮食计划数量，反之亦然。 客户还与所有者建立多对一关系。

所以，为了实现这种关系，我有两种方法。我想知道哪一种效果更好。

方法 1 在这种方法中，DietPlans 表将与Owner 表具有OneToMany 关系，并与客户表具有ManyToMany 关系。

Owner-

@Data
@Entity
public class Owner {

    @EmbeddedId
    private OwnerKey ownerId;

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "owner", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Customer> customers= new ArrayList<Customer>();


    @OneToMany(fetch = FetchType.LAZY, mappedBy = "owner", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Diet> dietPlans = new ArrayList<Diet>();
}

Customer 表-

   @Data
    @Entity
    public class Customer{

        @EmbeddedId
        private CustomerKey customerId;

        @ManyToOne(fetch = FetchType.LAZY, optional= false)
        private Owner owner;

        @ManyToMany(fetch = FetchType.LAZY, mappedBy = "subscribedCustomers")
        private List<Diet> subscribedDietPlans = new ArrayList<Diet>();
    }

Diet 的计划如下 -

@Data
@Entity
public class Diet {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;


    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumns({
        @JoinColumn(.....
    })
    private Owner owner;

   @ManyToMany(fetch = FetchType.LAZY, optional = false)
    @JoinColumns({
        @JoinColumn.....)
    })
    private List<Customer> subscribedCustomers = new ArrayList<Customer>();

}

不应允许客户创建任何饮食计划，而只需订阅由其所有者创建的饮食计划。

方法 2 在这种方法中，不是在dietPlans 表和Customer 表之间建立多对多关系，而是创建一个单独的SubscribedPlans 表，其中将包含来自DietPlans 表的引用（外键）。 SubscribedPlans 表将与客户表具有多对一关系。这样，客户就不会订阅不存在的计划。

就简单性而言，这两个中哪一个更好？另外，如果有更好的建模方法，请告诉我。

Answer 1

您的问题的答案取决于以下问题的答案

您是否看到需要投入更多资金的直接需求 用户订阅计划的数据？例如，说， 订阅计划的有效期限，定价 计划等。

如果答案是否定的，那么您只需要维护映射。在这种情况下，方法 1 效果更好。

如果答案是肯定的，那么您需要采用方法 2。因为SubscribedPlan 实体将演变并包含用户订阅的计划相关详细信息，例如持续时间、价格（它将是价格计划表的 FK）等.