多対多のテーブル設計についてご教授ください。

Question

以下のケースのテーブル設計について、ベターな設計がありましたらご教授いただけると幸いです。

●要件
ユーザーが主催するイベントを登録し、他のユーザーがそのイベントに参加することができるWEBサービスのDB設計

●エンティティ
・ユーザー
・イベント

●実現したいこと
ユーザーとイベントの関連性として、
そのユーザーが主催するイベントなのか、
そのユーザーが参加するイベントなのかを区別したい。

●考えたこと
ユーザーとイベントは多対多で紐づくので中間テーブルを作成し、フィールドには
ユーザーIDおよびイベントIDに加えて、
ユーザーとイベントの関係性が主催なのか、参加なのかを区別するフィールドをもたせる。

具体的なデータ例としては、
user_id：3
event_id：2
relation：'host'
のようなデータが投入される中間テーブルとなる。

上記のような設計よりベターな考え方がございましたら、
ご教授いただけると幸いです。

Answer 1

「主催者が1人固定なのか複数なのか」「主催者と参加者を共通にハンドリングしたい場面があるのか」というあたりが気になります。

• 主催者が1人固定であれば、イベント側に「主催者のuser_id」をもたせるのがいいでしょう。
• 主催者と参加者を共通ハンドリングしない場合、中間テーブルを主催者用・参加者用で分けるのも選択肢となりえます。

Comments

[m.ts10806]

>主催者が1人固定であれば
おお、、、そこの考慮も必要でしたね。

[satake-ze]

maisumakunさん、ありがとうございます！
そもそも仕様の検討が足りてませんでしたね。。

設計のご教授もありがとうございます、大変勉強になりました。
主催者は複数ユーザーであることも想定されますので、後者を検討させていただきます。

Answer 2

イベントには必ず主催者が存在する仕様なのでしたらorganizer_id (主催者ID)を入れておけば良いと思います。
user_idとイコールなら主催者　それ以外なら参加者と区別ができます。

※maisumakunさんの回答より別段の考慮が必要な場合を追記
もし主催者が複数名になる可能性があるのでしたらorganizerテーブルを用意し、
そこに主催者グループを登録し、organizer_idにはユーザーIDではなく主催者グループIDを登録すると良いです。

Comments

[satake-ze]

mts10806さん
その発想はありませんでした、ありがとうございます！

また、追記までご丁寧にありがとうございました、
ご提示の設計も検討させていただきます。

[m.ts10806]

ヒントになったようで何よりです。
たぶん「これで完璧」ということはなく実装中に設計不備が分かることもあると思いますので、
大枠の方針を決めておいて、後々微調整でも良いとは思います。

[satake-ze]

やはり設計段階で完璧な設計をするということはなかなか難しいようですね。。
ある程度仕様を固めた上で実装に移りたいと思います。
ありがとうございましたm(__)m

[m.ts10806]

実装中に不整合に気づいて設計書直すとかありますし、
実装中に気づかなくても結合テストで気づいたりとかもあります。
がんばってください。