OneToMany - 結合テーブルと外部キーの違いは何ですか？

Question

@JoinColumnアノテーションを使用して@OneToManyリレーションシップジョインテーブルを無効にする可能性があります。デフォルトは結合テーブルです。

たとえば、実動システムのメリットとデメリットは何ですか？
いつ結合テーブルを使用する必要がありますか？

ありがとうございます。

Answer 1

@OneToManyは、の一方向の関係を使用する場合にのみ、結合テーブルを作成します。言い換えれば

、あなたがEmployeeとProjectエンティティを持っているとを次のようにEmployeeエンティティが（これらの事業体にはorm.xmlエントリが存在しないと仮定）定義されている場合：

@Entity 
public class Employee { 
    // ... 

    @OneToMany 
    Set<Project> projects; 
} 

@Entity 
public class Project { 
    // ... 
} 

JPAプロバイダが作成されます。結合テーブル（ProjectのEmployeeエンティティへの参照がないので、@OneToMany注釈にはmappedBy属性はありません）。一方

、あなたは双方向の関係を使用します場合：「多」側は、この関係の外部キーを格納するためにも使用されるように

@Entity 
public class Employee { 
    // ... 

    @OneToMany(mappedBy="employee") 
    Set<Project> projects; 
} 

@Entity 
public class Project { 
    // ... 

    @ManyToOne 
    Employee employee; 
} 

参加の表は、使用されません。

ただし、定義済みのmappedBy属性の双方向@OneToManyの関係がある場合でも、結合テーブルの使用を強制できます。あなたは関係の所有側に@JoinTable注釈を使ってそれを達成することができます。

既述のように結合テーブルを使用する場合（単方向@OneToManyの関係）、前述したように@JoinColumnを使用する可能性もあります。

FKをテストして、テーブルのパフォーマンスの違いを自分でテストすることをお勧めします。私はちょうどより少ない結合（この場合：FK）がより良いパフォーマンスを持つように思われることができます。

また、DBAがデータベーススキーマを定義することがあり、マッピングを既存のスキーマに合わせるだけでよい場合もあります。そうすれば、FKやジョイントテーブルの上に選択肢がないので、選択肢があります。

Answer 2

多型のために結合テーブルが必要です。たとえば、従業員とマネージャが同じプロジェクトをリンクしており、リレーショナルDBレベルでクラスごとに1つの戦略でマッピングされている場合、そのプロジェクト（ID = 1、emp_id = 10）を知る唯一の方法はマネージャemp_idをmanager_2_employee表に置くことです。このような状況にない場合、emp_idはプロジェクトに直接入ることができます。

Answer 3

上記のコメントで説明したように、デフォルトでは、hibernateはjoinテーブルに行きます。 これにより、db正規化が向上します。

選択した場合、JoinColumnは、SQLクエリの余分なテーブルの結合の必要性が除去されるため、結合テーブルよりも優れたパフォーマンスを提供します。