web-dev-qa-db-ja.com

外部キー参照に非ID列を使用しても大丈夫ですか？

以下のようなテーブルがあります

_Role(Role ID, Name, Other_Columns)
Command(Command ID, Name, Other_Columns)
_

関連付けテーブルRoleCommandがあります。 RoleCommand(RoleName, CommandName)の代わりにRoleCommand(Role ID, Command ID)を使用してもかまいませんか。この場合、名前を参照に使用すると、関連付けテーブルの読み取りや入力が簡単になると思います。 RoleCommandには、挿入クエリを手動で入力することに注意してください。 Web UIはありません。 Name列に一意のキー制約と外部キー参照を設定します。この種の参照を本番環境で使用する人はいますか？ほとんどの場合、関連付けテーブルに使用されているのはIDだけです。

更新：

nameの挿入クエリがRoleCommand内にネストされたSELECTクエリを使用すると、ID値を取得できないため、外部キー参照にVALUESを使用することを検討しています。名前。エラーを回避するために、挿入クエリでIDだけを使用したくありません。

databasedatabase-designrelational-database
4
TechCrunch
  • 名前をFKとして使用することは、少なくとも通常ではありません。通常、FKは親テーブルのFKを指します。
  • nameを両方のテーブルのPKにして、IDを完全に削除することもできます。
  • 良いビジネスキーが存在する代理PKを使用することの欠点の1つを見つけました。連想表を読んで理解できるはずです。 すべてのデータがアプリケーションに属していない場合、それは組織に属しています（別の回答から取得）。

私が推奨するのは、サロゲートを使用することをすでに決定している場合は、サロゲートに固執し、FKにそれらを指すようにすることです。

また;名前列に一意の制約を作成した場合、それらはキー列と見なされるので、理論的にはFKをそれらにポイントできますが、私はそれがエレガントでないと思います。

9
Tulains Córdova

間違いは、Nameの方が読みやすいため、IDではなくNameを使用することです。あなたがすべきことはあなたのIDをもっと読みやすくすることです。

RoleCodeではなくRoleIDと考えてください

Role(RoleCode Pk, Name, Other_Columns)
Command(CommandID PK, RoleCode FK, Other_Columns)

サンプルデータ

RoleCode      Name              Other_Columns
--------      ----              -------------
Admin         Administrator
PwrUser       Power User
User          Standard User

これで、参照整合性は安全です。

6
Morons

はい、一意の制約を持つ列でなければならない場合を除き、外部キー参照に非ID列を使用することは問題ありません。

外部キーの基本的な定義は次のとおりです。「あるテーブルの主キーが別のテーブルの外部キーとして機能する」。標準SQLでは、外部キーの参照は、参照されるテーブルのPRIMARY KEYまたはUNIQUE KEYである必要があります。

非ID列を主キーとして使用できる場合は、それで問題ありません。ただし、ID列を外部キー参照として使用することにはいくつかの利点があります。

  1. ID列、特にIDENTITY列である列は、ほとんど更新されないという意味で（場合によっては）インデックスとしても適しています。テーブルから行を削除しないと、インデックスの断片化が減少します。

  2. Create_date/entry_date列がなく、データを入力された順序で確認する必要がある場合。IDとしてID列があると、それが可能になります。

  3. 複合キーは機能しますが、単一の主キーの方が扱いやすい場合があります。たとえば、削除を実行すると、特定の行を選択するのが非常に簡単になります。多くの場合、数値キーで検索する方が効率的です。

ありがとうございました ！

2
Purvi Barot