0

FK を PK として使用する、またはサロゲート PK を使用し、JPA コンテキストで FK を FK として使用するベスト プラクティスは何ですか? レガシ データベースがあるため、FK を PK としてマップする必要があると言う人をほとんど見かけませんでした。つまり、新しいテーブルの作成を制御できる場合は、次の構造を使用することをお勧めします。

TABLE_1
-------
ID (PK)
...

TABLE_2
-------
ID (PK) 
TABLE_1_ID (FK)

それ以外の：

TABLE_2
-------
TABLE_1_ID (PK) and (FK)
4

3 に答える 3

1

多対1の関係では、常に最初に提示した代替案を使用してください。

一部の1対1の関係では、悪影響なしにテーブルがマージされる場合があります。

2番目の選択肢が本当に役立つのは、Martin Fowlerによって提示されたように、クラステーブル継承モデルを使用してスーパークラス-サブクラス階層を実装する場合です。この場合、NULLの数を減らすために、サブクラステーブルをスーパークラステーブルと区別する必要があります。しかし、関係は1対1です。

サブクラステーブルのPKとFKの両方と同じキー機能を作成し、FKがスーパークラステーブルの一致するエントリを参照するようにすることで、必要に応じて、特殊なデータを一般化されたデータと非常に簡単に結合できます。これは「貧乏人の相続」と言えます。

于 2012-07-31T09:58:42.620 に答える
0

@MapsId注釈を探していると思います。

于 2012-08-03T01:14:57.010 に答える
0

この特定のケース (1 対 0..1 の関係) では、2 つのテーブルを 1 つにマージすることを検討してください。

それらが意図的に分割されている場合 (「垂直」パーティショニングなど)、PK と FK の両方で同じフィールドを優先します。

キーを小さくできる場合にのみ、別のキーを追加することを検討してください1。ただし、追加のインデックスの必要性2 、クラスタリングに対する潜在的な敵意3、ひし形の依存関係をモデル化する必要性4とのバランスを取ってください。

1 例 は文字列であり、整数TABLE_2.TABLE_1_IDを作成できるためです。TABLE_2.ID

2 すべての新しいインデックスは INSERT を遅くし、WHERE 句によっては UPDATE と DELETE を遅くする可能性があります。また、データが追加されると、キャッシュが「小さく」なるという追加の圧力がかかります。

3 クラスター化されたテーブルのセカンダリ インデックスには PK のコピーが含まれている必要があり、行を検索するときに (最初にインデックスを検索し、次に PK を検索する) 二重検索が発生する可能性があります。

4 「ひし形」の両方の「辺」で識別関係を使用することは、ひし形の「下部」が単一の「上部」を参照することを保証するために必要な場合があります。

于 2012-07-31T09:30:14.133 に答える