我想了解何時將多個外鍵包含到表中以及何時使用關聯表。何時在單個表中使用多個外鍵與使用關聯表？
編輯：添加a diagram，希望能夠更容易理解。
我有一個設置系統，許多設置是特定於一個部門或分類。因此，例如，像「每隊人數」這樣的設置在第1分區A級比第3分區A級可能不同。第1分區A級比第1分區的「最低分數」可能不同C.顯然也有一些設置與我認爲應該在同一個表中的分區或分類無關。
所以我可以做到這一點的一種方法就是把div/class ID作爲FKs放在設置表中。然後，任何不依賴於其中一個或另一個的設置對於這些ID都是空的。
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)
由於只有一個組合的分類，分類和設置密鑰，應該工作，對嗎？但是這種「感覺」不知何故是錯誤的 - 就像在競爭對手的桌子上所有不同的事件一樣。我也不能保證他們不會拿出一些他們希望稍後應用設置的其他類別/類型。所以這讓我想這樣做：
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)
我認爲這將允許更容易生長，當他們拿出了一些新的類別（只創建「類」和「settings_to_categories」表）。但是，我可能會在設置表（[id]，「min_score」，5）和相關項目的多個幾乎相同的表（id，label，description）中有一整套幾乎重複的記錄 - 創建一個獨特的設置記錄。
然後當他們說他們想要男士和女士的不同設置時會發生什麼？我只是在設置表中添加一個額外的字段，並將'男性'和'女性'字符串硬編碼到記錄中，除了性別特定的設置外，其他位置都爲空。或者在事物的另一端，創建一個只有兩條記錄的單獨的「性別」表，並在用戶表中使用它？突然間，我在：
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類，類別綠色，流氓，男性玩家vs女性玩家，我不需要重新設計我的數據庫或應用程序，以便輕鬆獲取/設置任何不同的設置。
我相信這不是一個新概念。這必須是某處公認的設計模式，但是很難嘗試尋找方法和方法來處理可能有3（或5或8）種關聯單個數據庫實體的不同方式的情況。
我目前傾向於關聯表方法（重要的標準化），但我並不是真正的DBA。那麼我在做一個愚蠢的設計決定？這種方法的負面和挑戰是什麼？還有一種不同的方法會更好嗎？