Q&A
それが必要ならば無理に別テーブルにする必要はないんじゃないかなあ。ただ、各サービスに対するユーザごとの付帯情報が必要なら分けてもいいかもしれません。このへんどうするかは、現状と将来の設計をどうしていくかを見据えて判断するんでしょうかね。
ご意見を伺いたいです。
会員機能があるサービスを構築しているのですが、ユーザーのテーブルが大きくなってしまい、
テーブル構成を見直したいと思っています。
例えば、下記のようなカラム構成のテーブルがあるとします。
| カラム名 | 概要 |
|---|---|
| id | ユーザーID |
| password | パスワード |
| name | 名前(漢字、ページ内の表示するユーザー情報) |
| name_kana | 名前（ひらがな） |
| age | 年齢 |
| is_service_a | Aサービスを利用できる権限がある |
| is_service_b | Bサービスを利用できる権限がある |
ログインに必要な情報はIDとPasswordだけです。
仕様上、IDとPassword以外はnullにはなりませんし、必ず１ユーザーあたり必ず１件のデータです。
そのため、必ずし正規化する必要性はないかもしれません。
このような構成の場合、テーブルを分けますか？
私が考えている構成
テーブル構成を見やすくするために下記に分けるのも有効なのではないかと思います。
- age、name_kanaは、
user_profilesのようなテーブルを用意して表示情報を分ける - is_service_a、is_service_bは、
user_optionsのようなテーブルを用意してサービスの利用情報を分ける
users
ログインに必要な最低限の情報テーブル。
ユーザー名も頻繁に使うのでこっちに含める
| カラム名 | 概要 |
|---|---|
| id | ユーザーID |
| password | パスワード |
| name | 名前(漢字、ページ内の表示するユーザー情報) |
user_profile
サービスに関係ない個人情報をまとめたテーブルです。
| カラム名 | 概要 |
|---|---|
| user_id | ユーザーID |
| name_kana | 名前（ひらがな） |
| age | 年齢 |
user_options
サービスに関係する情報をまとめたテーブル。
| カラム名 | 概要 |
|---|---|
| user_id | ユーザーID |
| is_service_a | Aサービスを利用できる権限がある |
| is_service_b | Bサービスを利用できる権限がある |
懸念点
- テーブルを分ければ分けるほどリレーションが大きくなるので不用意に分ける必要性はないのではないかと考えています。
- もしかしたら、見やすいと思うのは自分だけかもしれないため、分けない方が良いのではないか？
ご指摘ありがとうございます。
おっしゃる通りテーブルを分ける必要性はありません。
情報量が多くなってきたなと感じると、落とし所に悩んでしまう場合が有りまして…
いただいたご指摘も参考にさせていただきます。
回答4件
0
自分ならこうします。
投稿2019/09/29 13:15
退会済みユーザー
総合スコア0
ご回答いただきありがとうございます。
確かに、紐づいているサービスで有無を確認する方法がありますね。
もしサービスの種類が増えたらどうなりますか？
その場合は、現状だとusersにサービスのテーブルを追加していくことになります。
そう考えると、ご回答いただいた用にservicesのテーブルを別途用意して中間テーブルで紐付けていく方法が良いですね。
私の質問に不備があり恐縮なのですが、
実際には構築しているテーブルで、サービス内のパラメータ（音量の初期値、機能の有効/無効など）の管理をしたい場合です。
例えば、アプリケーションのオプション設定画面のようなものを想定しています。
もうしわけないのですが、追記された文の意味がわかりません。これは質問ですか？
失礼しました。
> もしサービスの種類が増えたらどうなりますか？
とお伺いしましたので、情報不足かと思い追記致しました。
元の質問からそれるので不要でしたね。
ご回答していただかなくても問題ありません。
0
あくまで私がやるなら、ですが
リレーションが１：１になるテーブル分けはあまりしたくないので
ユーザーテーブルからは
is_service_a、is_service_bだけを取り外す
| カラム名 | 概要 |
|---|---|
| id | ユーザーID |
| password | パスワード |
| name | 名前 |
| name_kana | 名前（ひらがな |
| age | 年齢 |
そのうえで、サービスがどのようなものかわからないので何とも言えませんが
user_optionsテーブル案のような構造にするとサービスが増えたときに列を増やす＝テーブル構造を変える必要が出てきてしまうのでまずサービスマスタテーブルを作成
| カラム名 | 概要 |
|---|---|
| code | サービス固有のcode（主キー） |
| name | サービスの名前 |
で、次はユーザとサービスをつなぐテーブルを作成
| 列1 | 列2 |
|---|---|
| user_id | ユーザーID |
| service_code | サービス固有のcode |
で、ユーザとサービスをつなぐテーブルにデータがあったらサービスを利用できる権限がある、と判断する
といった感じでしょうか……
あとユーザテーブルは年齢ではなく生年月日を入れる方がおすすめです。
登録時点での年齢は1年後には変わってしまうので生年月日と今現在の日付から計算した方が正確になります。
投稿2019/09/29 13:10
総合スコア610
ご回答いただきありがとうございます。
> user_optionsテーブル案のような構造にするとサービスが増えたときに列を増やす＝テーブル構造を変える必要が出てきてしまうのでまずサービスマスタテーブルを作成
確かにおっしゃる通り、今後新しい要素が増える度に列が追加されない構成は良いですね。
勉強になりました。
> あとユーザテーブルは年齢ではなく生年月日を入れる方がおすすめです。
> 登録時点での年齢は1年後には変わってしまうので生年月日と今現在の日付から計算した方が正確になります。
ご指摘いただきありがとうございます。
年齢の場合は、年月日で管理した方が良いですね。
0
すでに回答がでているとおり「特定のサービスを利用できる権限」は
正規化して別テーブルで管理する手もあるし
場合によってはset型やJSON型などで1カラムで管理する手もあるかと
投稿2019/09/30 04:41
編集2019/09/30 04:42
総合スコア114843
0
ベストアンサー
ユーザーのテーブルが大きくなってしまい、テーブル構成を見直したいと思っています。
この大きくというのが、容量的な事を言われているのであれば、構成からは必ずしも同一人物を特定できませんから、同じ人で複数のアカウントが登録されているという事はありませんか？
IDとかパスワード忘れた人は新規登録するしかないですよねこれだと。
なので未使用のデータがどんどん溜まっていく。
それが理由なら、user_profile部分を必須項目として充実させないと駄目ですね。
（サイズを考慮して別テーブルにするかどうかは要件次第）
容量ではなく項目数の話をされているのであれば、気にする必要性は感じません。
何れにしても、user_optionsに関連するものは、正規化した方が良いかとは思いますけど。
投稿2019/09/30 02:46
編集2019/10/01 09:14
総合スコア25195
ご回答いただきありがとうございます。
ご説明が不足しており申し訳ありません。
容量的なものではなく項目的な理由です。
質問で掲載したテーブルは状況を簡単に説明するために簡略化しましたが、
詳細に書くと、サービス内のパラメータ（例えば、動画の音量初期値や、サービスの機能無効有効の切り替え）管理です。
サービス毎のような書き方をしてしまい分かりづらい例えで申し訳ありません。
項目数が多いから見易さを考えてという観点で、テーブルを同じキーで分割するという事は、キー項目が増えるので、容量的にも結合コスト的にも無駄になります。
正規化から逸れてしまいますよ。
構造化したいなら、項目名にプレフィックスを付けるとかで工夫されてはどうでしょうか。
他のDBMSであれば構造体をユーザーで定義できるものもあったりするんですけどね。
user_optionsについて、権限だからという理由で、正規化していないのなら、それはちょっと違いますよ。
度々ご指摘いただきありがとうございます。
分割についてご意見をいただけてとても参考になりました。
> 構造化したいなら、項目名称にプレフィックスを付けるとかで工夫されてはどうでしょうか。
> 他のDBMSであれば構造体をユーザーで定義できるものもあったりするんですけどね。
なるほど。
回避策についてもご教示いただきありがとうございます。
知識不足でユーザーを定義出来るシステムを存じ上げておりませんが、選択肢がある事にも気づけました。
> user_optionsについて、権限だからという理由で、正規化していないのなら、それはちょっと違いますよ。
はい。
saziさんのご回答や皆さんのご回答を拝見して気づくことができました。
気をつけます。
> ユーザーを定義出来るシステム
ではなくて、独自に型（構造体で）を定義できるDBMSがあるという事です。
失礼しました。
DBMSの事をデータベース管理システムと書かずに、システムと略して記載してしまいました。
DBMSの事は理解しております。
あなたの回答
tips
プレビュー
