複数の外部キーをテーブルに含めるタイミングと連想テーブルを使用するタイミングを理解しようとしています。
編集：うまくいけば理解しやすくするために図を追加しました。
多くの設定が部門または分類に固有の設定システムがあります。したがって、たとえば、「チームあたりの数」のような設定は、ディビジョン 1 のクラス A とディビジョン 3 のクラス A では異なる場合があります。また、「最小スコア」は、ディビジョン 1 のクラス A とディビジョン 1 のクラス A とで異なる場合があります。 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 つしかないので、それでうまくいくはずですよね? しかし、それはどういうわけか「間違っている」ように感じます-ほとんど、競合しているさまざまなイベントをすべて競合他社の表に入れるようなものです. また、後で設定を適用したい追加のカテゴリ/タイプを考え出さないことも保証できません。だから私は次のようなことをしたいと思うようになります:
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)
これにより、新しいカテゴリができたときに成長が容易になると思います (「categories」テーブルと「settings_to_categories」テーブルを作成するだけです)。しかし、設定テーブル ([id]、「min_score」、5) にほぼ重複するレコードのセット全体と、関連するアイテムの複数のほぼ同一のテーブル (id、ラベル、説明) がある可能性があります。 1 つのユニークな設定レコードを作成します。
では、男性と女性で異なる設定が必要だと言うとどうなりますか? 設定テーブルに追加のフィールドを追加して、「男性」と「女性」の文字列をレコードにハード コードし、性別固有の設定を除いてどこでも 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 ではありません。それで、私は愚かな設計上の決定を下していますか？そのアプローチのマイナス/課題は何でしょうか? まだ別のアプローチが良いでしょうか？