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

Question

我想在两个表之间创建以下关系

表-

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

因此，为了实现这种关系，我有两种方法。我想知道哪一个更好。

方法1在此方法中，DietPlans表将与Owner表具有OneToMany关系，而ManyToMany表将与Customer表保持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在这种方法中，我将创建一个单独的SubscribedPlans表，它将包含来自DietPlans表的引用(外键)，而不是dietPlans表和Customer表之间的多到多关系。SubscribedPlans表将与Customer表有多到一个关系。这样，客户就不能订阅不存在的计划。

在简单性方面，哪一个更好？另外，如果有更好的方法来做这个模型，请告诉我。

Answer 1

你的问题的答案将取决于以下问题的答案

，您是否立即看到需要将更多的数据与用户的订阅计划相对应的需求？例如，例如，预订计划的有效期、计划的定价等等。

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

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