リレーショナルデータベースで「アクティブグループ」の関係を表現する方法は？

Question

1人のユーザーが多くの「グループ」に所属できる「ユーザー」の表を保管しておく必要があります。各グループ内には、グループ固有の設定が多数あります。

これは、Groupテーブル、Userテーブル、UserGroupSettings相互参照[1]テーブルを使用して達成するのが非常に簡単です。ここに問題はありません。

私は、ユーザーと彼らが現在 "アクティブ"であるグループとの間に "アクティブグループ"の関係を表現する方法を取り組んでいます。ユーザーは、一度に1つのグループ内で非アクティブまたはアクティブにすることができます。それらが非アクティブであるとき、それらのUserGroupSettingsは維持されます。

Userテーブル内のnull可能な「active_group」列を持つという明白なアプローチは、データベース・スキーマが特定のGroupおよびUserに対してUserGroupSettings表内に行が存在する必要があるという事実を強制しないため、 ID。同様に、Userテーブルに "settings_id"外部キー列を設定しても、それが指し示す設定行が実際に同じユーザーを参照することは強制されません。

最適なソリューションはありますか？

1. https://en.wikipedia.org/wiki/Associative_entity

Answer 1

ユーザーのグループ設定を参照する外部キーで、user_active_group、たとえば、のテーブルを必要とするように聞こえます。

これらの行に何かがあります。 。 。

-- Assumes {group_id, user_id) is unique. 
create table user_group_settings (
    settings_id integer primary key, 
    user_id integer not null, 
    group_id integer not null, 
    bunch_of_settings char(1) not null default 'X', 
    unique (user_id, group_id) 
); 

create table user_active_group (
    -- This primary key constraint means each user can have only one row. 
    user_id integer not null primary key, 
    group_id integer not null, 
    -- This foreign key constraint means there must also be a row in user_group_settings. 
    foreign key (user_id, group_id) references user_group_settings (user_id, group_id) 
    on update cascade, 
    active_group varchar(5) not null 
); 

カスケード更新は分かりやすいようです。カスケード削除はアプリケーションに依存します。