web-dev-qa-db-ja.com

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

ルックアップテーブル（またはコードテーブル、一部の人々はそれを呼び出す）は、通常、指定できる可能な値のコレクションです。あるコラム。

たとえば、次の2つの列を持つparty（政党に関する情報を格納するためのもの）という名前のルックアップテーブルがあるとします。

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

そして、そのようなテーブルは次のデータを保持するとします：

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

party_code列は、値 'Republican'および 'Democratic'をテーブルの実際のキーとして保持しますが、UNIQUE制約を使用して設定されていますが、オプションでparty_code_idnをテーブルのPKとして定義しました（ただし、論理的にはparty_codeは主キー[PK]として機能する場合があります）。

質問

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

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

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

次のプロパティがあります1：

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

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

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

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

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

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

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

Import-Exportは別の方法で実行することもできます。つまり、look-up tableを再度入力してからre-seed代理列。私はこれが正しく行われていることを願っています。これは、可能性として聞いたことがあるものです。

1。+、-および=これらのプロパティの利点を示します。

質問

非常に重要：lookup（またはcode）テーブルとFK参照の間に違いがありますか？後者のアプローチ？彼らはまったく同じように動作すると思います。

関連資料

database-designforeign-keyprimary-keybest-practices
14
Nishant

IDNは、IDENTITY、SEQUENCEまたはAUTO_INCREMENTフィールド？ here と here をご覧ください。

図10の下の最初の参照のセクション5（データ要素としてのデータ値の誤用）に注意してください。

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

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

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

上記の2番目の参照から：

正規化は冗長データを排除するため、データの整合性を適用するタスクは非常に単純になりますが、MUCKを作成するプロセスはまったく別のものです。MUCKは冗長データを排除せず、冗長テーブルであると認識されているものを排除しますが、これから説明するように、テーブルの数を少なくしても、単純さと同じではありません。

また、関連するEAV（ Entity Attribute Value ）パラダイムを確認することもできます。このパラダイムは here を扱っています。

10
Vérace

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

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

コードは、外部キーとしてトランザクションテーブルに取り込まれます。これは短く、わかりやすく、「実際の」データとは多少独立しています。 a name を段階的に変更しても、コードの変更は示唆されません。ただし、共和党員 decampen masse の場合は、コードの変更が必要になる可能性があります。発生しません。

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

その他の例：国の場合は2文字または3文字のエンコード、通貨コードの場合は3文字のエンコード（GBP、USD、EUR）。短く、自己説明的で、変更されません（そして、それらにはISOがあります）。

10
Michael Green