0

Playerというテーブルが1つあります

  • プレーヤーID (PK)
  • その他の列

いくつかの列を含めるために、PlayerExtraInfo という名前の Player と1 対 1の関係を持つ別のテーブルを作成したいと考えています。したがって、いくつかのオプションがあります。

  1. 新しいテーブルを作成する代わりに、PlayerExtraInfo 列を Player テーブルに追加します。

  2. PlayerExtraInfo テーブルを作成し、Player テーブルに FK を設定します。

    プレイヤーテーブル

    • プレーヤーID (PK)
    • その他の列
    • PlayerExtraInfoID (FK)

    PlayerExtraInfoテーブル

    • PlayerExtraInfo (PK)
    • その他の列

  3. 反対: PlayerExtraInfo には、Player テーブルへの FK が含まれています。関係が 1 対 1 であることを確認するために、一意の制約を追加します。

    プレイヤーテーブル

    • プレーヤーID (PK)
    • その他の列

    PlayerExtraInfoテーブル

    • PlayerExtraInfo (PK)
    • その他の列
    • PlayerID (FK、ユニーク)

  4. オプション 3 に似ていますが、PK と FK を 1 つに混合します。この場合、外部キーも主キーになります。

    プレイヤーテーブル

    • プレーヤーID (PK)
    • その他の列

    PlayerExtraInfoテーブル

    • PlayerID (PK、FK)
    • その他の列

オプション 1、2 が正しいことはわかっていますが、パフォーマンスの問題により、オプション 3 または 4 を選択しています。これらの 3 と 4 のオプションについて考えると、オプション 4 についていくつか疑問が生じます。私の質問は次のとおりです。

  • 選択肢 3 と 4 は正しいですか?
  • オプション 4 は通常のフォームを壊しますか?
  • 私が考えていなかった別のオプションはありますか？
4

2 に答える 2

4

あるテーブルを別のテーブルで拡張する場合、主キーを外部キーとして使用することはまったく問題ありません (また、推奨されます)。

于 2012-08-17T12:06:01.050 に答える
1

オプション 2、3、4 は正しいですが、オプション 1 が最高のパフォーマンスを発揮するものだと思います。クラスタ化インデックスを使用する場合でも、余分な結合は余分な結合です。また、外部キーは、対象のテーブルに関してパフォーマンスを低下させます (単一ではなく、多数の外部キーがパフォーマンスを低下させることは認めます)。

拡張テーブルにメイン テーブルのレコードの一部しかない場合、または異なるパーティションに 2 つのテーブルが必要な場合を除いて、そのテーブルをピースに分割する理由は考えられません。

于 2012-08-17T12:27:38.587 に答える