MySQLでnullが発生する場合のtableの切り方について

Question

いつもここでは、大変お世話になっております。
今回新しいサービスを開発することになり、ユーザテーブルの切り分けで多少悩んでおります。
皆様のご意見を伺えれば幸いです。

userテーブル
|user_id|user_email|user_pass|user_cus_id|user_last_name|user_first_name|
|:--|:--:|--:|
|1|[e-mail]|12345678|hogefuga|山田|太郎|

現在はこのようなテーブル構成としており、省略しておりますが実際は12レコード存在しています。
ユーザーが登録する時に2種類のタイプ（フリーとプレミアム）を考えており、
フリーではメールアドレスとパスワードだけで登録頂く予定です。

そうすると、フリーで登録した場合は残り9つのカラムが
nullになるため運用上どうなのかと疑問に思いました。

user_free

user_id	user_email	user_pass
1	[e-mail]	12345678

user_premium
|user_id|user_cus_id|user_last_name|user_first_name|
|:--|:--:|--:|
|1|hogefuga|山田|太郎|

としてテーブルを分け、null値が発生しないように努めるべきなのかどちらが良いかご意見を頂ければ幸いです。

個人的にはnullが増えるのもキモチワルイですが、テーブル数が増えるのもキモチワルイです。
開発時点なのでなんとも言えませんが10万レコードを超えるようなサービスでも無い気がします（超えたらどうしよう）

以上となりますが、よろしくお願いいたします。

Comments

[yoorwm]

なぜ、「キモチワルイ」のかを説明してみてください。
（nullがどのような意味を持っていると思っていますか？）

[terapro]

null撲滅委員会の記事を拝読しました。
http://mickindex.sakura.ne.jp/database/db_getout_null.html

ユーザテーブルは今後四則演算で集計もするはずなので、null排除は必要と考えます。
しかし、テーブル数が多くなるとどのテーブルで何を参照しているのか後でわからなくなる可能性があるなと考え、一般的には皆様どちらを採用されているのかをお伺いしたかったです。

[m.ts10806]

想定のユーザー数、割合はどれくらいでしょうか

[terapro]

初年度1万ユーザ、3年で10万ユーザ。
フリー80%、プレミアム20%と予想しています。

[terapro]

例えば、プレミアム登録の方の住所を取ったり取るのをやめたり、電話番号を取ったり取るのをやめたりと、ABテストをするとどうしてもnullは発生してしまうと思うので、それなら１つのテーブルでまとめてしまっても一緒じゃないかと。むしろnullを撲滅すると、そのたびにtabelが増えて残骸が出そうな気がしております。

[yoorwm]

なるほど。ありがとうございます。理由分かりました。
設計によりますが、そちらの記事によると、0で代替する、とかあるのでuser_cus_idはdefault 0で、他は空き文字列でいいんじゃないですかね。

[terapro]

必須項目と任意項目でテーブルを分けて、必須項目はnull無し、任意項目のnullは0で代替しようと思います。ありがとうございます。

Answer 1

本来であればuser_idで紐付けるように、フリー部分とプレミア部分をわけるのが妥当でしょう。

Comments

[yambejp]

ただし、カラム数が12で、データ量も10万そこらならSQLで
管理する容量としては大したことないですし、
プレミアでつかうカラムも固定であれば、正規化はさほど
気にしなくてもよい気がします。
一応フリーなのかプレミア７日をジャッジするフラグの
カラムだけ用意した方が良いと思います

[terapro]

貴重なご意見ありがとうございます！

Answer 2

テーブルを分割するかどうかは、
フリーからプレミアム、または、その逆にデータが変化するかどうか
によって決まるのではないでしょうか？

上で定義したテーブルに対して発行する下記のクエリと

SELECT 
    * 
FROM 
    user
;

下で定義した分割したテーブルに対して発行する下記のクエリで結果は同じになると思います。

SELECT
    *
FROM
    user_free as uf
    LEFT JOIN
        user_premium as up
    ON  uf.user_id = up.user_id
;

同じ結果が取得可能なら、
変更の際にプレミアムに変更されたり、
フリーに変更になったりしたときにどこのカラムが変更になるのかが気になります。

単純にNULLになる値を避けたいのなら、
テーブルを単純に分けるだけでなく、
「ランク」のようなカラムを設けないと、
フリーのユーザだけを取り出すのが難しいのではないでしょうか？

Comments

[terapro]

ありがとうございます。参考にさせていただきます。

Answer 3

ログイン情報テーブル(ユーザー区分と共通項目含む)と
ユーザー情報テーブルをわければ済みそうに思います。

完全に分けてしまうとuser_idの重複に対する配慮や、懸念されてる通りどっちを参照すべきか分からなくなったり、実装上でのリスクが多いです。
「ユーザー区分がプレミアムならユーザー情報テーブルを結合する」という形にするとnullもなくなり無駄なデータもなくなると思います

Comments

[terapro]

ユーザランクと必須項目を用意したloginテーブルと、任意項目のuserテーブルを分ければ良いですね！これならバランスが取れそうです。ありがとうございます。

[m.ts10806]

ユーザーランクとやらの切り替えがあるのでしたらそのuserテーブルのデータを追加したり削除したりがありえます。
例えば降格してまた復帰する場合があるのか、あるとしたら降格時に残しておくのか削除してはじめから登録させるのか
含めてデータ管理の仕様をしっかり決めておいてください

[terapro]

はい！ありがとうございます！