Q&A
一般と講師の実行するタスクの差としては、「教材を投稿できるかどうか」ぐらいになります。
共通部分と機能が違う部分で正規化をするという考え方もあるんですね！とても勉強になります。
##解決したいこと
データベースのテーブル構造として考え方があっているか意見を聞きたい。
特に、ユーザーのテーブルを一般会員と講師会員で分けるべきなのか意見聞きたいです。
現在、勉強のために自作でPHPのアプリを作成しようと思っています。
※PHPを学び始めて2ヶ月ぐらいです。
コンセプトは「ブログの教材を閲覧できる」アプリを考えています。
機能は以下の通りです。
■トップ
・会員登録(一般)
・講師で登録
■ユーザー
・ユーザーの新規登録
・ログイン
・パスワードリセット
・ログアウト
■メイン
・教材の登録
・教材一覧
・教材詳細
・教材編集
・教材削除
・マイページ
これを元に以下のようにテーブルを作成してみました。
usersテーブル(ユーザー)
id
post_id
name
email
password
role
postsテーブル(投稿)
id
img
title
contents
price
level
post_at
ユーザーテーブルでは、
roleで一般か講師かで権限を分けようとしてます。(0または1)
この場合、
一般会員でログイン→role=0と判定。教材は投稿できないようにしたいのでpost_idはnull設定
講師でログイン→role=1と判定。教材が投稿できるのでpost_idで講師が投稿した教材を判定。
このような実装で問題ないでしょうか？
回答3件
0
ベストアンサー
内容的には、postsがusersを外部参照する形であるので、usersにpost_idを持つのではなく、postsにuser_idを持たせましょう。
※そうでないと、post_id毎にusersのデータを保持しないと駄目になってしまいます。
投稿2021/03/25 04:00
総合スコア25206
0
一般と講師の実行するタスクと権限にどのくらい差があるかによりますが
面倒であればすべての項目を羅列したテーブル1つで管理するのが楽
（mysql自体のログインユーザー管理がそういう仕組）
ただそれぞれやることが大幅に違うなら共通部分と機能が違う部分で
正規化をするほうがSQLを利用する本来のあるべき姿です
投稿2021/03/25 00:28
総合スコア115010
0
ユーザーテーブルでは、
roleで一般か講師かで権限を分けようとしてます。(0または1)
というのはあんまりよく無いです。
0=一般
1=講師
をフィールド名からは判断することが出来なくて、所謂マジックナンバーになってしまい、将来的にroleが増えた場合に3,4,5とさらにマジックナンバーが増殖してしまう原因となります。
将来に渡ってに講師か一般かだけで分けるなら、boolean型のis_tutorにするとか、
将来にロールが増える可能性があるのであれば、別にroleテーブルを作って、その主キーを格納するrole_id（外部キー制約により、存在しないroleのIDを指定することを回避）の様な構成にする方が良いです。
一般会員でログイン→role=0と判定。教材は投稿できないようにしたいのでpost_idはnull設定
講師でログイン→role=1と判定。教材が投稿できるのでpost_idで講師が投稿した教材を判定。
講師のpost_idにはどんな値が入るのでしょう？(ユーザーIDでしょうか)
そのユーザーが講師か否かはusers.roleを参照すればわかる事なので不要です（同じ役割をする情報を複数のところに持つのは色々な弊害があって良くない事とされています）
教材投稿のタイミングでusers.roleチェックして講師じゃなければ投稿出来ない様にする方が良いです。
投稿2021/03/24 15:18
総合スコア18716
ご回答いただきましてありがとうございます！
roleのテーブルを作成する方法もあるんですね。勉強になりました。
確かに将来的にさらに権限ユーザーが増加したときにとても考え方として参考になりました。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2021/03/25 09:37
退会済みユーザー
2021/03/25 09:38
2021/03/25 10:05 編集
退会済みユーザー
2021/03/25 10:06