この記事に出くわした後：http： //diovo.com/2008/08/are-foreign-keys-really-necessary-in-a-database-design/
データベースを設計するときは、外部キーを使用することをお勧めします。しかし、いつ使いすぎているのでしょうか。
たとえば、他のプログラムが次の列で参照する機械部品情報のリストを格納するために使用されるメインテーブルがあるとします。
可能なすべての色、単位、およびカテゴリのリストを含むテーブルを作成し、それらを機械部品情報テーブルの対応する列への外部キーとして設定する必要がありますか？外部キーを使用する利点は、これらすべての追加のテーブルと関係を作成しているという事実をどの時点で重視しますか？
データベースに存在する既知の有効な値のみが存在することを確実に示すことができる属性は、外部キーで保護する必要があります。それ以外の場合は、アプリケーションコードと、将来作成されるインターフェイスで無効な値をキャッチすることしか期待できません。
より多くのテーブルと関係を持つことは悪いことではありません。唯一の問題（通常は1つではありません）は、これらの関係を適用するために使用されるインデックスを維持するためのオーバーヘッドに関係しています。パフォーマンスの問題が発生するまでは、列ごとに外部キー関係を作成する必要があります（値をリストに対して検証する必要があるため）。
パフォーマンスの正確さを犠牲にする前に、パフォーマンスの考慮事項はかなり悲惨なものでなければなりません。
すべての設計は競合する目標の妥協点であるため、簡単な答えはほとんどありません（間違ったものを除く）。
私は確かに、名前、色、カテゴリ、測定単位などの個別の測定値を独自のキーテーブルに入れます。標準サイズのパッケージ（つまり、1、6、12など）のユニットがない限り、可変メジャー（コスト、ユニット数など）はそれほど多くありません。
データベースを設計する最も簡単な方法は、要件から始めることです。1つの古典的な方法論では、要件はER（エンティティ関係）モデルに要約されます。このモデルでは、エンティティ間の関係は発明されておらず、発見されています。それらがデータベースがカバーすることになっている情報の範囲内にある場合、それらはモデルの一部です。限目。
そこから、データベース設計に目を向けると、必要な関係がすでにわかっています。テーブルの構造についていくつかの決定を行う必要がありますが、主キーを参照するほとんどすべての外部キーは、要件の直接的な結果です。
もちろん、設計プロセスの過程で要件を自由に変更できる場合は、何でもできます。
次元モデリングは、質問のすべてのポイントをうまくカバーします。外部キーの関係が多すぎると、クエリのパフォーマンスが低下する可能性があります。キンボールのグループリーダーは、ディメンションデザインの優れた入門書であり、顧客の要件をスキーマに変換する方法です。
http://en.wikipedia.org/wiki/Dimensional_modeling
質問する主な質問は、「データをどの程度制約する必要があるか」です。機械部品の色については、色の選択肢としてシエナやカモミールを焦がさないようにするのが一番の利益になると思います。したがって、これらのルックアップテーブルが最適です。