Q&A
なぜ、「キモチワルイ」のかを説明してみてください。
（nullがどのような意味を持っていると思っていますか？）
いつもここでは、大変お世話になっております。
今回新しいサービスを開発することになり、ユーザテーブルの切り分けで多少悩んでおります。
皆様のご意見を伺えれば幸いです。
userテーブル
|user_id|user_email|user_pass|user_cus_id|user_last_name|user_first_name|
|:--|:--:|--:|
|1|yamada@gmail.com|12345678|hogefuga|山田|太郎|
現在はこのようなテーブル構成としており、省略しておりますが実際は12レコード存在しています。
ユーザーが登録する時に2種類のタイプ（フリーとプレミアム）を考えており、
フリーではメールアドレスとパスワードだけで登録頂く予定です。
そうすると、フリーで登録した場合は残り9つのカラムが
nullになるため運用上どうなのかと疑問に思いました。
user_free
| user_id | user_email | user_pass |
|---|---|---|
| 1 | yamada@gmail.com | 12345678 |
user_premium
|user_id|user_cus_id|user_last_name|user_first_name|
|:--|:--:|--:|
|1|hogefuga|山田|太郎|
としてテーブルを分け、null値が発生しないように努めるべきなのかどちらが良いかご意見を頂ければ幸いです。
個人的にはnullが増えるのもキモチワルイですが、テーブル数が増えるのもキモチワルイです。
開発時点なのでなんとも言えませんが10万レコードを超えるようなサービスでも無い気がします（超えたらどうしよう）
以上となりますが、よろしくお願いいたします。
null撲滅委員会の記事を拝読しました。
http://mickindex.sakura.ne.jp/database/db_getout_null.html
ユーザテーブルは今後四則演算で集計もするはずなので、null排除は必要と考えます。
しかし、テーブル数が多くなるとどのテーブルで何を参照しているのか後でわからなくなる可能性があるなと考え、一般的には皆様どちらを採用されているのかをお伺いしたかったです。
想定のユーザー数、割合はどれくらいでしょうか
初年度1万ユーザ、3年で10万ユーザ。
フリー80%、プレミアム20%と予想しています。
例えば、プレミアム登録の方の住所を取ったり取るのをやめたり、電話番号を取ったり取るのをやめたりと、ABテストをするとどうしてもnullは発生してしまうと思うので、それなら１つのテーブルでまとめてしまっても一緒じゃないかと。むしろnullを撲滅すると、そのたびにtabelが増えて残骸が出そうな気がしております。
なるほど。ありがとうございます。理由分かりました。
設計によりますが、そちらの記事によると、0で代替する、とかあるのでuser_cus_idはdefault 0で、他は空き文字列でいいんじゃないですかね。
必須項目と任意項目でテーブルを分けて、必須項目はnull無し、任意項目のnullは0で代替しようと思います。ありがとうございます。
回答3件
0
テーブルを分割するかどうかは、
フリーからプレミアム、または、その逆にデータが変化するかどうか
によって決まるのではないでしょうか？
上で定義したテーブルに対して発行する下記のクエリと
SQL
1SELECT 2 * 3FROM 4 user 5;
下で定義した分割したテーブルに対して発行する下記のクエリで結果は同じになると思います。
SQL
1SELECT 2 * 3FROM 4 user_free as uf 5 LEFT JOIN 6 user_premium as up 7 ON uf.user_id = up.user_id 8;
同じ結果が取得可能なら、
変更の際にプレミアムに変更されたり、
フリーに変更になったりしたときにどこのカラムが変更になるのかが気になります。
単純にNULLになる値を避けたいのなら、
テーブルを単純に分けるだけでなく、
「ランク」のようなカラムを設けないと、
フリーのユーザだけを取り出すのが難しいのではないでしょうか？
投稿2019/12/24 03:01
総合スコア81
0
ベストアンサー
ログイン情報テーブル(ユーザー区分と共通項目含む)と
ユーザー情報テーブルをわければ済みそうに思います。
完全に分けてしまうとuser_idの重複に対する配慮や、懸念されてる通りどっちを参照すべきか分からなくなったり、実装上でのリスクが多いです。
「ユーザー区分がプレミアムならユーザー情報テーブルを結合する」という形にするとnullもなくなり無駄なデータもなくなると思います
投稿2019/12/24 02:50
総合スコア80875
ユーザランクと必須項目を用意したloginテーブルと、任意項目のuserテーブルを分ければ良いですね！これならバランスが取れそうです。ありがとうございます。
ユーザーランクとやらの切り替えがあるのでしたらそのuserテーブルのデータを追加したり削除したりがありえます。
例えば降格してまた復帰する場合があるのか、あるとしたら降格時に残しておくのか削除してはじめから登録させるのか
含めてデータ管理の仕様をしっかり決めておいてください
はい！ありがとうございます！
あなたの回答
tips
プレビュー
