ルックアップテーブルの主キーとしてintを使用する理由

ルックアップ値を主キー（ほとんどの場合は文字列）として使用するのではなく、なぜルックアップテーブルの主キーとしてintを使用する必要があるのか​​を知りたい。

intではなくnvarchar（50）を使用すると、多くのレコードを持つテーブルにリンクされている場合、より多くのスペースが使用されることを理解しています。

一方、ルックアップ値を直接使用すると、基本的に結合を行う必要がなくなります。参加が常に必要な場合、これは大きな節約になると想像できます（Webアプリで作業しているので、これはかなり重要です）。

int主キー（特にルックアップテーブル用）を使用することの利点は、「行うべき標準的なこと」以外に何ですか？

あなたの質問への答えは物理的ではなく論理的です-あなたが調べる値はビジネス上の理由で変わるかもしれません。たとえば、顧客を電子メールアドレスでインデックス付けした場合、電子メールアドレスが変更されるとどうなりますか？明らかにこれはすべてのルックアップテーブルに適用されるわけではありませんが、アプリケーション全体で同じ方法で行う利点は、コードが簡単になることです。すべてが内部的に整数→整数の関係であれば、カバーされます。

Sandyへのコメントを読んでください。おそらくこの場合、本当に必要なのは、外部キー/ルックアップテーブルではなく、チェック制約です。

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

これを実行すると、以下が得られます：

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

これは効率的で高性能な方法ですが、もちろん、新しいフレーバーを追加するとコードが変更されるという欠点があります。アプリケーションで実行することはお勧めしません。このDBに接続するすべてのアプリケーションで実行する必要があるため、検証を実行するためのコードパスが1つしかないため、これは最もクリーンな設計です。

「ルックアップ値を直接使用する」–ルックアップテーブルの実際の目的とは少し矛盾します。なぜあなたはそのようなテーブルを保持しているのですか？ルックアップではない場合。
あなたの質問を誤解したかもしれません。msdnのルックアップテーブル定義を次に示します。

ルックアップテーブルは、別のテーブルの外部キーフィールドの値に基づいて、あるテーブルの情報を表示するために使用されます。たとえば、販売データベース内の注文のテーブルを考えてみましょう。Ordersテーブルの各レコードには、どの顧客が注文したかを示すCustomerIDが含まれています。CustomerIDは、Customersテーブルの顧客レコードを指す外部キーです。（Ordersテーブルから）注文のリストを表示する場合、CustomerIDではなく、実際の顧客名を表示することができます。顧客名は顧客テーブルにあり、Ordersテーブルからデータを提示しているため、ルックアップテーブルを作成する必要があります。このテーブルは、OrdersレコードのCustomerID値を取得し、その値を使用して関係をナビゲートし、より多くを返します読み取り可能な顧客名。

ルックアップテーブルの目的を説明できますか？次のような静的データを保存するために使用され、これらのレコードは他のテーブルレコードの入力ではありませんか？

フレーバー テーブル

Orange  
Pista  
Mango

上記があなたの状況であれば、ルックアップテーブルを使用しないことをお勧めします。おそらく、これらのリスト値をWebアプリケーションにハードコーディングしてください。これにより、不要なデータベースクエリを回避できます。

「ルックアップテーブル専用」で質問を修飾したため、答えはおそらく「スペースを節約する」まで簡略化されています。

その修飾子を削除すると、質問は「なぜ自然キーよりも代理キーを使用するのか？」になると思います。 私が書いた代理キーのサポートに次の

「より広い複合キーの代わりに1つの整数値を移行することには多くの利点があります。物理モデル全体で一貫性があり、複合キーの移行と比較して、コストよりも多くのスペースを節約し、I / Oを削減します。正規化されたモデル。さらに、モデルとクエリ結合の理解を簡素化します。」

これが主に「標準的なこと」になった理由です。残念な副産物は、人々が代理キーを投げ、候補キーが何であるかを考えないことです...しかし、今、私たちはあなたの質問の外に出ています:)

私がいつも使用する理由の1つは、誰かがルックアップテーブルの値のスペルを間違えた場合、たとえばオレンジの代わりにOranegを使用すると、ルックアップテーブルの値を変更するのがはるかに簡単だからです。

番号の主キーを持つルックアップテーブルでは、ルックアップテーブルで値を変更するだけで済みます。

プライマリキーとして値を使用するルックアップテーブルは、ルックアップテーブルと、それが使用されたメインテーブルのすべてのレコードで変更する必要があります。

IDを定義すると、一意性を保証することもできます。しかし、たとえば電子メールを一意の識別子として使用する場合、一意性の責任を信頼できない第三者に移します。