4

データベースに属性 A1、A2、A3...An およびA1、A2 と A3 が一緒に複合キーを形成できる場合、複合キーの代わりに代理キーを使用する方がよいでしょうか?

サロゲート キーを使用すると、レコードの挿入実行速度が向上します(これは、複合キーよりもサロゲートをサポートます) 。代理キーに対する複合キー)。

このような条件を考えると、どちらがパフォーマンスの面で優れていますか? 代理キーまたは複合キー?

4

2 に答える 2

2

代理主キーを実装するかどうかを選択する際の主な関心事は、パフォーマンスではありません。

理想的な主キーにはいくつかの望ましい属性があることがわかりました

  • simple (単一列、ネイティブ データ型)
  • 一意(正に重複する値はありません)
  • null 以外(すべての行に値があります)
  • 不変(一度割り当てられると変更されることはありません)
  • 匿名(「情報」を持たない)

主キーとして選択された候補キーがこれらのプロパティをすべて備えている必要があるという「規則」はありませんが、これらはさまざまな理由から望ましいプロパティです。

すべてのテーブルに主キーが必要であるという「規則」さえありません。しかし、そうすることが望ましいと思います。

成功したソフトウェア システムは、代理キーと自然キーを使用して構築されています。


パフォーマンスに関しては、実証できるほどの違いはありません。ただし、これを考慮してください。エンティティ テーブルに、いくつかの「大きな」列で構成される複合キーである主キーがある場合、そのエンティティ テーブルへの外部キー参照を持つすべてのテーブルで同じ大きな列を繰り返す必要があります。一部のストレージ エンジン (InnoDB) では、これらがすべてのインデックスで繰り返されます。

しかし、実際の決定要因はパフォーマンスではありません。(パフォーマンスが主キーとして候補キーを選択する際の決定要因であるべきだと示唆する人は、それについて十分に考えていません。)


「操作が簡単」である限り、多くの開発者は、2 つ、3 つ、またはそれ以上の列で構成される複合キーよりも、1 つの列を主キーとして使用する方が簡単だと感じています。

主キーとして自然キーを選択した一部の開発者は、後に候補キーの選択に悩まされています。自然キーだったからではなく、開発が進むにつれて「新しい」要件が「発見」され、主キーとして選択した候補キーが実際には常に一意であるとは限らないことが判明したためです。変更を免除されていないか、実際には匿名ではありませんでした。

自然キーと複合キーを PRIMARY KEY として使用して成功したソフトウェア プロジェクトは数多くあります。代理キーを PRIMARY KEY として使用して成功したのと同じように。

于 2015-05-24T05:14:24.770 に答える