私はデータベースを設計しており、ユーザーを含むユーザーテーブルと、ユーザーのグループを含むグループテーブルがあります。
これらのグループには、所有者(それを作成したユーザー) と、グループの一部である一連のユーザー (Whatsapp グループなど) が含まれます。
これを表すために、私はこのデザインを持っています:
表のowner
列は必要だと思いますか。Group
グループの所有者を簡単に知ることができるテーブルにowner
列を追加できるかもしれません。Group
私はデータベースを設計しており、ユーザーを含むユーザーテーブルと、ユーザーのグループを含むグループテーブルがあります。
これらのグループには、所有者(それを作成したユーザー) と、グループの一部である一連のユーザー (Whatsapp グループなど) が含まれます。
これを表すために、私はこのデザインを持っています:
表のowner
列は必要だと思いますか。Group
グループの所有者を簡単に知ることができるテーブルにowner
列を追加できるかもしれません。Group
owner
を追加しない場合group
、どこに追加しますか? これとは別に私が見る唯一の方法は、にブール値isowner
を追加することusergroup
です。とにかく、所有者が 1 人しかいない場合、これは意味がありません。N
所有者がいる場合は、それが進むべき道です。
あなたは正しい道を進んでいますが、所有者が所有するグループに実際に属していることを確認するには、もう 1 つの手順が必要です。
UserGroup {groupID, userID} を参照するグループ {groupID, owner} に FOREIGN KEY があります。
DBMS が遅延外部キーをサポートしている場合、所有者を NOT NULL にして、グループが所有者なしにならないようにすることができます。それ以外の場合は、NULL 可能のままにしておくことができます (また、DBMS がMATCH SIMPLE FK をサポートしている場合は、循環参照による「鶏が先か卵が先か」の問題を解決することができます。ほとんどの場合はそうです)。
4 つのテーブルが必要です。
ユーザー
ユーザー・グループ
グループ
UserRole (UserGroup に関連付けられている) - グループ内のユーザーの役割 (管理者/所有者など) を表示します。 - 役割が管理者および一般ユーザーの場合、代わりに UserGroup の Binary 列を使用できます。
解決策がすでに提案されていることは知っていますが、より良い解決策があると確信しています...
上位レベルでは、所有者の概念は、ユーザーとグループの間に存在する関係のプロパティと見なすことができます。理想的には、UserGroup テーブルのフィールドとして設定する必要があります。
これは、ブール値フィールド、またはuserGroupNatureOfRelation
「所有者」、「参加者」、「ユーザー」などの値を保持できる一般化されたフィールド、またはステータスのいずれかです。
もちろん、このようなソリューションを使用すると、「グループごとに所有者は 1 人だけ」など、特定のビジネス ルールを実装できます。必要に応じて、他のより洗練されたビジネス ルールを実装できます。また、次のようなフィールドを追加して複雑なレベルを追加することもできます。
userGroupRelationStartDate
userGroupRelationEndDate
集団と個人の関係の本質を時系列で追うことができます...
もちろん、「いらない」と言うこともできます。しかし、そのような「オープン」モデルを実装するのに、今考えている以上の費用はかかりません。その後、何らかの理由で、近い将来または遠い将来にビジネス ルールを変更または改善する必要が生じた場合でも、モデルは有効かつ効率的であり続けます...
つまり、このモデルを使用すると、ビューの構築とデータの操作がはるかに簡単になるはずです。したがって、これはそれを採用する正当かつ直接的な理由です!