1

私は一種のソーシャル ネットワークを作成しており、他のユーザーをフォローできるユーザーがいます。だから私は次のようなエンティティを持っています:

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

    @ManyToOne
    private User followedUser;

    //more fields

    ...
}

FollowedUser エンティティに複数のフィールドがあるため、ManyToMany 関係を持つことはできません。今、私が持っている質問は次のとおりです。

  1. 複合キーまたは生成された ID (代理キー) を使用する必要がありますか? 代理キーが提案されているトピックに関する次のリンク ( 1、2、3 ) を読みましたが、具体的なケース (複合キーが 2 つの代理外部キーで構成される場合) に適用されるかどうかはわかりません。 . また、ここ( 4 )には、「複合主キーは通常、レガシーデータベースからマッピングするときに発生する」と書かれているため、推奨されていないと思います。
  2. 複合キーを使用する必要がある場合、 @IdClass (ここで推奨5 ) または @EmbeddedId (ここで推奨6 ) またはその他のオプションを使用する必要があるかどうかわかりません。私はそれが問題ではないと思いますが。
  3. 代理キーを使用する必要がある場合、複合候補キーを繰り返さないようにする方法がわかりません。ここ ( 7 ) で一意のインデックスについて読みましたが、それがその問題の正しい回避策であるかどうかはわかりません。
4

1 に答える 1

1

1.代理キーの使用をお勧めします。レコードのデータベース ID をそのビジネス ID から分離すると便利だと思います。2 つの概念が混在している場合、それらを正しくモデル化し、後で再モデル化するのは面倒です。あなたはいくつかの良い答えを参照しているので、おそらく主な長所と短所を認識しています。ここでそれらを繰り返す必要はありません. 追加のポイントの 1 つは、適切UUIDに実装するように代理キーに依存できることです。複合キーがコレクションとデータベースの両方でうまく機能するようにそれらを実装するのは難しい場合があります。equalshashCode

ユースケースに関しては、ユーザー間の接続はそれ自体のエンティティと見なされ、自動生成された代理 PK を持つことができます。DB 内のビジネス キー属性の一意性を強制できます。pt.3 を参照してください。

2.私の知る限り、EmbeddedIdとのどちらを選択するかIdClassは、ほとんど好みの問題です。IdClassid 属性を照会するときにナビゲーションを追加する必要がなくなるため、私は を好み ます。

... WHERE a.id.attribute = :attとEmbeddedId対。

... WHERE a.attribute = :att対IdClass

あなたがリンクしている議論には説得力がありません。複合キーは、エンティティの最も特徴的な属性で構成される傾向があります。たまたまDBキーとして使用されているため、それらを別のクラスに隠すのは私には厄介に思えます。

3.一意のインデックスは、属性の組み合わせの一意性を保証するための優れた方法のように見えます。この回答を読むことをお勧めします。小さな例があります。

まだ JPA 2.1 を使用していない場合は、ここで説明されているように、一意の制約を使用することをお勧めします。

于 2014-06-30T13:08:40.120 に答える