学校向けの Web アプリケーションを設計しています。これまでのところ、これらのテーブルを持つデータベースにこだわっています。
ユーザー
- ID
- ユーザー名
- パスワード
プロフィール
- ユーザー ID (外部キー)
- 名前
- 苗字
- セックス
- group_id (外部キー)
- （その他基本情報）
...そして、イベント、委員会、グループなど、現在は関係のない他のテーブル。そのため、ユーザー テーブルにはログインに関する基本情報が格納され、プロファイル テーブルにはユーザーに関するすべての個人データが格納されます。
これで、プロファイル テーブルの *group_id* 列には、グループテーブルでユーザーが現在登録されているグループの ID 列を参照する外部キーが含まれます。ユーザーは一度に 1 つのグループにしか登録できないため、テーブルを追加する必要はありません。
問題は、 group HAS MANY profilesのような関係を宣言することはあまり意味がないということです。代わりに、リレーションはgroup HAS MANY usersである必要がありますが、 usersテーブルには認証情報しか格納されていないため、*group_id* 列をusersテーブルに配置する必要があります。
一方、ORM を使用してグループに登録されているすべてのユーザーを一覧表示し、プロファイルではなくユーザー コレクションを取得したいと考えています。私の見方では、users テーブルは「親」のようなもので、profiles テーブルは users テーブルを拡張するものです。
イベントの出席を設定するときにも同じ問題が発生します。events_attendance テーブルでプロファイルを外部キーとして参照する必要がありますか? または、ユーザー ID を参照する必要がありますか?
もちろん、両方のソリューションを実装して機能させることができますが、どちらが最良の選択でしょうか?
少し掘り下げたところ、両方のソリューションが3NFに準拠していることがわかったので、理論的には正しいですが、データベースを正しい方法で設計するのに苦労しています。