JPA-复合键与多对多表中生成的id

我正在创建一种社交网络，我的用户可以跟随其他用户。所以我有一个实体，比如：

@Entity
public class FollowedUser{
    @ManyToOne
    private User user;

    @ManyToOne
    private User followedUser;

    //more fields

    ...
}

我不能有太多的关系，因为我的FollowedUser实体中有更多的字段。现在，我的问题是：

我应该使用复合键还是生成的id（代理键）？我已经阅读了关于建议使用代理键的主题的以下链接（，），但我不知道它们是否适用于我的具体情况（我的复合键将由两个代理外键组成）。这里（）还说“复合主键通常在从遗留数据库映射时出现”，所以我认为不鼓励使用它们

如果我应该使用复合键，我不知道是否应该使用@IdClass（此处推荐）或@EmbeddedId（此处推荐）或任何其他选项。虽然我想这没关系

如果我应该使用代理密钥，我不知道如何仍然使复合候选密钥无法重复。我在这里读过（）关于唯一索引的内容，但我不知道这是否是解决这个问题的正确方法

---

1。我建议使用代理键。我发现将记录的数据库标识与其业务标识分开很有帮助。如果这两个概念是混合的，那么对它们进行正确的建模并在以后重新建模可能会很麻烦。您引用了一些好的答案，因此您可能知道主要的优点和缺点，无需在此重复。另外一点是，您可以依赖代理键（如

UUID

）来正确地实现

equals

和

hashCode

）。为组合键实现这些功能，以便与集合和db一起很好地发挥作用，这可能是一件棘手的事情

至于您的用例，用户之间的连接可以被视为自己的实体，并具有自动生成的代理PK。您可以在DB中强制实现业务密钥属性的唯一性，请参见第3部分

2.AFAIK，在

EmbeddedId

和

IdClass

之间做出决定主要是一个品味问题。我更喜欢

IdClass

，因为它避免了在查询id属性时添加导航：

。。。其中a.id.attribute=：att

with

EmbeddedId

vs

。。。其中a.attribute=：att

vs.with

IdClass

我觉得你的论点没有说服力。复合关键点往往由实体的最具特征的属性组成。将它们隐藏在另一个类中，因为它们碰巧用作DB键，这对我来说似乎很尴尬

3.唯一索引看起来是保证属性组合唯一性的好方法。你可能想读书

---

如果您还没有使用JPA2.1，您可能需要使用独特的约束，如。

非常感谢kostja提供了非常详细的答案。