私は、テーブルに複数の外部キーをいつ含めるべきか、関連テーブルを使用するかを理解しようとしています。1つのテーブルで複数の外部キーを使用する場合と、関連テーブルを使用する場合はどちらですか？
編集：理解しやすくするためにa diagramを追加しました。
多くの設定が部門や分類に固有の設定システムがあります。したがって、たとえば、「1チームあたりの数」という設定は、部門1、クラスAが部門3、クラスAで異なる場合があります。また、「最小スコア」は部門1、クラスAが部門1よりも異なる場合がありますC.明らかに、私が同じテーブル内になければならないと感じる部門や分類とは関係のない設定もあります。
私がこれを行う方法の1つは、div/class IDをFKとして設定テーブルに入れることです。次に、どちらか一方（またはどちらか）に依存しない設定は、それらのIDに対してnullになります。
divisions
----------
id (int)
label (varchar)
description (varchar)
classification
--------------
id (int)
label (varchar)
description (varchar)
settings
---------
id (int)
division_id (int) (FK)
class_id (int) (FK)
key (varchar)
value (varchar)
分割、分類、および設定キーの組み合わせが1つしかないので、正しく動作するはずです。しかし、それは何らかの形で間違っていると感じます。競合他社のテーブルで競合するさまざまなイベントを置くのとほとんど同じです。後で設定を適用したいと思ういくつかの追加のカテゴリ/タイプが出てこないことも保証できません。私は、彼らはいくつかの新しいカテゴリ（単に「カテゴリ」と「settings_to_categories」テーブルの作成）を思い付くとき、これは容易な成長を可能にするであろうと思います
divisions
----------
id (int)
label (varchar)
description (varchar)
classifications
--------------
id (int)
label (varchar)
description (varchar)
settings
---------
id (int)
key (varchar)
value (varchar)
settings_to_divisions
-------------------------
setting_id (int)
division_id (int)
settings_to_classifications
------------------------------
setting_id (int)
class_id (int)
：だからそれはように私が何かをしたくなります。しかし、私はおそらく、設定テーブル（[id]、 "min_score"、5）と複数のほぼ同じテーブル（ID、ラベル、説明）のレコードを、固有の設定レコードを1つ作成します。
次に、男性と女性の設定が異なるとしたらどうなりますか？私は設定テーブルに余分なフィールドを追加し、レコードに「Male」と「Female」の文字列をハードコードしますか？性別に固有の設定を除いてどこでもnullですか？または、物事の反対側では、2つのレコードだけを持つ別の「ジェンダー」テーブルを作成し、それをユーザーテーブルにも使用しますか？それはほとんど... 過度正規化された感じを開始します
divisions
---------
id (int)
label (varchar)
description (varchar)
classifications
---------------
id (int)
label (varchar)
description (varchar)
categories
----------
id (int)
label (varchar)
description (varchar)
type
----
id (int)
label (varchar)
description (varchar)
gender
------
id (int)
label (varchar)
description (varchar)
settings
---------
id (int)
key (varchar)
value (varchar)
settings_to_divisions
---------------------
setting_id (int)
division_id (int)
settings_to_classifications
---------------------------
setting_id (int)
class_id (int)
settings_to_categories
----------------------
setting_id (int)
category_id (int)
settings_to_type
----------------
setting_id (int)
type_id (int)
settings_to_gender
------------------
setting_id (int)
gender_id (int)
：突然、私は時です。多分それは私だけです。
私はこの設定をインテリジェントに設計しようとしているため、一部の設定がすべてのディビジョン3プレーヤーに適用されていても、追加のカテゴリが必要であり、アプリケーションがディビジョン3、クラスA、カテゴリグリーン、ローグ、男性のプレイヤー対女性のプレイヤー、私は自分のデータベースやアプリケーションをあまりにも多く設計する必要がないので、異なる設定が必要なものを簡単に取得/設定できます。
これは新しい概念ではないと確信しています。これはどこかで認識されている設計パターンでなければなりませんが、単一のデータベースエンティティを3つ（または5つまたは8つ）異なる方法で処理する方法やアプローチを検索しようとするのは難しいです。
私は現在、アソシエーション・テーブル・アプローチ（重要な正規化）に傾いていますが、実際にはDBAではありません。だから、私は愚かな意思決定をしていますか？そのアプローチの否定的/挑戦は何でしょうか？まだまだ違うアプローチが良いでしょうか？