私は2つのテーブルを持っています:
1) ユーザー
2) シナリオ
それらの間の関係は次のように説明できます。
ユーザーは 0 個以上のシナリオを持つことができます
シナリオは正確に 1 人のユーザーに関連付ける必要があります
1 つの方法は、User_Scenario_rels を作成し、ユーザーとシナリオ テーブルの ID を使用して関係を作成することです。しかし、これはベストプラクティスでしょうか? これは 1 対多の関係ですか?
私は2つのテーブルを持っています:
1) ユーザー
2) シナリオ
それらの間の関係は次のように説明できます。
ユーザーは 0 個以上のシナリオを持つことができます
シナリオは正確に 1 人のユーザーに関連付ける必要があります
1 つの方法は、User_Scenario_rels を作成し、ユーザーとシナリオ テーブルの ID を使用して関係を作成することです。しかし、これはベストプラクティスでしょうか? これは 1 対多の関係ですか?
これは「1 対多」の関係です。1 つのシナリオには 1 人のユーザーがいて、1 人のユーザーには多くのシナリオがあります。
通常、シナリオ テーブルの "user_id" 列によってモデル化されます。
現場で実践されているデータベース設計に関しては、「ユーザーが 0 個以上のシナリオを持っている」と「ユーザーが 1 個以上のシナリオを持っている」という区別はありません。理論的には、すべてのユーザーに少なくとも 1 つのシナリオが必要であるというルールを課したい場合は、制約を実装します。
1 つの方法は、User_Scenario_rels を作成し、ユーザーとシナリオ テーブルの ID を使用して関係を作成することです。しかし、これはベストプラクティスでしょうか? これは 1 対多の関係ですか?
それが要件に適合し、1:n の関係を実装するかどうかは、キーと制約が適切かどうかによって異なります。これが唯一の方法ではなく、この特定のケースでは、シナリオがユーザーなしで存在できるようになります。
create table users (
user_id integer primary key
);
create table scenarios (
scenario_id integer primary key
);
-- Separate table allows users to have zero scenarios.
create table user_scenarios (
user_id integer not null references users (user_id),
scenario_id integer not null references scenarios (scenario_id),
-- This primary key lets each user have multiple scenarios
primary key (user_id, scenario_id),
-- This unique constraint allows each scenario id number to
-- be used only once. (So it's associated with only one user.)
unique (scenario_id)
);
Neville K が言ったように、シナリオのテーブルに null 非許容の user_id 列を含めることをお勧めします (そして簡単です)。