WEBアプリケーションDB設計に関して

Question

WEBアプリケーションを作るにあたりDB設計を行っています。

Comments

[m.ts10806]

まず、どんな形でもいいので自分でやってみてください。
「適切か」を求めるのであれば始めから他者に意見を求めるのではなく「こういう要件を元にこういう設計をしてみたけどどうか」という風に質問された方がよりよいアドバイスを得られると思います。
ほぼ、作業依頼です。

[encho]

自分で調べながら概念モデルまでは考えてみたのですが、
そこから同テーブルにつなげていいのか分からなかったので質問させていただきました。

[yodel]

生徒と先生との関係を1:1でいいのか1:多でいいのか、多:多なのかは要件次第では？

[encho]

お聞きしたかった部分は、
生徒と先生との関係ではなくユーザー対生徒、ユーザー対先生の関係でした。

Answer 1

教師と生徒は属性が違うので、これはテーブルを分けた方が良いでしょう。
ユーザーはログインするためのアカウント情報と考えると、これも分けていた方が良いでしょうね。

教師と生徒はユーザーへの外部キーの関係になると思います。

Comments

[encho]

ありがとうございます。
この場合はユーザー対教師、ユーザー対生徒は
１対1の関係となりますが問題はないということでしょうか？

またメッセージやレビューはどのように教師や生徒へ紐づけるべきでしょうか？

[sazi]

あるユーザーが教師と生徒を兼ねる事があるなら別ですけど、そうでなければそれぞれ1:1で問題無いと思います。

メッセージなどのその他については、質問からは要件が読み取れませんので、回答しかねます。

Answer 2

• 生徒テーブル
• 教師テーブル
• レビューテーブル

があれば、最低限仕様は満たすでしょう

Comments

[yambejp]

メッセージ機能は何をしたいかわかりませんが
登録したeメールを仲介する感じですかね
ただしブロックする機能が必要になるかも

マッチング機能は専用のテーブルが必要かもしれません
（レビューテーブルと教師テーブルからある程度は
条件とれそうですけど・・・）

[encho]

ユーザーの情報に関するテーブルは
ユーザーテーブル、生徒テーブル、教師テーブルという形で３つのテーブルを考えていたのですが
ユーザーテーブルという形ではテーブルは必要ないということでしょうか？

[yambejp]

> ユーザーテーブル

自分が生徒なら生徒テーブル、自分が教師なら教師テーブルで
十分な気もしますが、生徒テーブル・教師テーブルに何を
保持させたいかによりますね
それぞれにidのみ保持させるなら、細かい情報はユーザーテーブルで
管理してよいかもしれません。
逆にユーザーテーブルにまとめるなら生徒テーブル・教師テーブルは
いらないかも・・・

[yambejp]

履歴やマッチング情報は
生徒＝教師テーブル的な中間テーブルを作るのが妥当です