リレーショナルデータベースのルックアップテーブルに関するベストプラクティスは何ですか？

ルックアップテーブル（またはコードテーブルと呼ばれることもあります）は、通常、特定の列に指定できる値のコレクションです。

たとえば、次のparty2つの列を持つ（政党に関する情報を保存するための）というルックアップテーブルがあるとします。

• party_code_idn、システム生成の数値を保持し、（ビジネスドメインの意味を欠いて）実際のキーの代理として機能します。
• party_codeは、ビジネスドメインの意味を持つ値を保持するため、テーブルの実際のキーまたは「自然な」キーです。

そして、そのようなテーブルは以下のデータを保持しているとしましょう：

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

party_code値は「共和党」と「民主党」を続けるの列は、テーブルの実際のキーであること、UNIQUE制約に設定されているが、私は必要に応じて添加party_code_idnし、論理的に言えば、ものの（表のPKとしてそれを定義しました、party_codeプライマリキー[PK]として機能する場合があります）。

質問

トランザクションテーブルからルックアップ値を指すためのベストプラクティスは何ですか？FOREIGN KEY（FK）参照を確立する必要があります（a）自然で意味のある値を直接参照するか、（b）値を代理しますか？

オプション（a）、たとえば

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

次のプロパティ¹があります。

1. エンドユーザーが読み取り可能（+）
2. システム間のインポート/エクスポートが簡単（+）
3. すべての参照テーブルで変更が必要なため、値を変更するのが難しい（-）
4. 新しい値を追加してもコストはかかりません（=）

アプリケーションプログラミングの専門用語で関数呼び出しから類推するのは、「値渡し」のようなものだと思います。

オプション（b）、たとえば

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

以下のプロパティがあります。

1. エンドユーザーが読めない（-）
2. 参照解除する必要があるため、インポート/エクスポートが困難です（-）
3. トランザクションテーブルに参照のみを格納しているため、値を簡単に変更できます（+）
4. 新しい値を追加してもコストはかかりません（=）

アプリプログラミング用語の関数呼び出しと比較すると、「参照渡し」に非常に似ています。

インポート/エクスポートは、別の方法で実行することもできます。つまり、ルックアップテーブルに再度データを入力してから、代理列を再シードするだけです。私はこれが正しいことを願っています、これは私がちょうど可能性として聞いたものです。

_{1. なお+、-及び=それらの特性の利点を示します。}

質問

かなり重要なこと：後者のアプローチを使用する場合、ルックアップ（またはコード）テーブルとFKリファレンスに違いはありますか？それらはまったく同じように機能すると思います。

関連資料

• ルックアップテーブルはどれほど重要ですか？

• コードまたはルックアップテーブルのベストプラクティス

• ルックアップテーブルのベストプラクティスDBテーブルまたは列挙

によってIDN、私はあなたがIDENTITY、SEQUENCEまたはAUTO_INCREMENTフィールドを意味すると思いますか？こことここを見てください。

図10の下にある最初のリファレンスのセクション5（データ要素としてのデータ値の誤用）に注意してください。

もちろん、営業担当者用に別のテーブルを作成し、外部キーを使用して参照することができます。できれば、上記のsales_person_idなどの単純な代理キーを使用してください。

そのため、この専門家は、代理キーを「保留」する必要があると考えています。これは実際には非常に基本的なSQLテクニックであり、日常のSQLで問題を引き起こすことはありません。図10にエラーがあるようです。SalesDataのsales_personはテキストではなく、代理キー（つまり、数字）である必要があります。これは上記の引用から推測しています。

どうしても避けなければならないのは、セクション（1）一般的なルックアップテーブルで説明されているエラーをコミットする誘惑（初心者のデータベースプログラマーにとって非常に一般的）です。これは一般にMUCK（Massively Unified Code Key）アプローチ（偶然ではありません:-)と呼ばれ、特にOTLT-One True Lookup Tableとしても知られているJoe Celkoによって、あらゆる種類の困難につながります。初心者プログラマーは、単一のコード/ルックアップ/どのようなテーブルでも「よりクリーン」であり、真実から遠く離れることができない場合により効率的であると感じているようです。

上記の2番目のリファレンスから：

正規化は冗長データを排除するため、データの整合性を強制するタスクが非常に簡単になりますが、MUCKを作成するプロセスは完全に別のものです。MUCKは冗長データを排除するのではなく、冗長テーブルと見なされるものを排除しますが、後で説明するように、テーブルの数が少ないと単純さは異なります。

また、ここで扱っている関連するEAV（エンティティ属性値）パラダイムもご覧ください。

2つのオプションの利点のいくつかを備えた3番目のアプローチがあります。実際のコードをコードテーブルに配置します。これによって私は、完全な価値の本質をとらえ、ユニークな短い文字列を意味します。あなたの与えられた例では、それは

Idn: 1
Name: Democrats
Code: D      (or DEM)

コードは、外部キーとしてトランザクションテーブルに格納されます。それは短く、わかりやすく、「実際の」データとは多少独立しています。名前を少しずつ変更しても、コードの変更は示唆されません。ただし、共和党員が一斉に脱キャンプする場合は、コードの変更が必要になる場合があり、それに付随する問題はサロゲートIDには影響しません。

このスタイルは、略語エンコーディングと呼ばれています。これに関するCelkoの執筆をお勧めします。Googleブックにはいくつかの例があります。「Celko encoding」を検索してください。

その他の例：国の場合は2文字または3文字のエンコード、通貨コードの場合は3文字のエンコード（GBP、USD、EUR）。短く、自己説明的で、変化しない（そして、それらのためのISOがある）。