よくある機能のDB設計。正解が欲しい。
DB設計
WEBサービスでよくある機能を実装しようした場合、どういうDB設計がベストなのかよくわからない。
- ユーザー認証
- メールアドレスログイン
- SNSログイン
- プロフィール登録
このあたりの標準機能を実現するのに、みなさんはどういうDB設計をされているのか気になっています。
以下、僕が考えたDB設計です。
おかしなところがあったらご指摘いただけると嬉しいです。
UserData
ユーザー一覧画面などの表示で使いそうなものはなるべくここに入れておいて、joinしなくても良いようにする。
- user_id
- nickname
- regist_date
UserDataProfile
性別だとか、自由テキストだとかなんでも入れておくテーブル。自由度高すぎか。
- user_id
- profile_type
- profile_value
UserDataAuth
メールアドレスと暗号化パスワードを保存しておく。極力引き出さないように、UserDataとは別テーブルに保存。
- user_id
- mail_address
- password
UserDataSNSAuth
TwitterなどのSNSログインもあることを考慮。
- user_id
- sns_type
- twitterなどの値
- sns_id
- twitterアカウントなどの値
- sns_auth_token
- ログイン後のトークン
僕がつくるんだったら、ここまで細分化することはないですね。
マスタのような増減があるものは別管理にしますが、なるべく同じ情報はひとつのテーブルにまとめます。テーブル分けすぎると連結させないといけなくなって複雑化しますので・・・。
上でいうと性別はマスタ化する必要はないのでわざわざテーブルつくりません。
●UserData
user_id
nickname
gender
mail
password
sns_type
sns_id
sns_auth_token
regist_date
というようにひとつのテーブルで十分だと思います。
回答ありがとうございます！
一気に一つにまとめてしまうんですね。
なんとなく、テーブルは別けた方がいいのかと思ってました。
これはとても参考になりました。
申し訳ないのですが、追加で質問があったりします。
例えば、詳細なユーザープロフィールなどが例としてあげられるかと思います。
・一言メッセージ
・twitterアカウント名
・住んでいる場所
などなど。
運用していく上で項目が増えていきそうな場合、
1) カラムをどんどん追加しますか？
2) カラムを追加しないように、key - valueの形式で持たせますか？
運用開始してレコード数が多くなってからカラムを追加すると、処理にえらい時間がかかってしまうため、メンテが必要な印象で。
だったらkey - value形式で持たせてしまってもいいのかな？とか思ってしましました（どこかでkey-value形式はSQLアンチパターンと見たような気がしますが）。
細かい質問なのですが、よければご教示ください！
上で挙げられている例では増減ないので、カラムをUserDataに追加します。
そうじゃなく例えば、ユーザープロフィールに「スキル」という項目がある場合、「プログラミング、デザイン」のように複数考えられますよね。そういう場合は別テーブルにします。
●UserData
id
...
●UserSkill
id
skill_name
...
●UserSkillData
id
user_id
skill_id
のように中間テーブルをつくって連携させたりします。
カラムを追加していく、了解です！
なるほど、こちらも参考になりました！
わざわざご回答いただきありがとうございます。
いま勉強しているLaravelと、ご教示いただいたDB設計でサービス開発していきたいと思います。