データベースのテーブル分割について

Question

現在、Ruby on Rails 4.2.6 と MySQL 5.5 を使用してアプリケーションを開発しています。

##聞きたいこと

たとえば、以下のようなユーザーの情報をもつテーブルがあったとします。

users
 - id: integer
 - email: string
 - name: string

もしユーザーの設定機能を追加する場合、
以下のように新しい user_settings テーブルを作成すべきなのか、
users テーブルに設定のためのカラムを追加すべきなのかを知りたいです。

user_settings
 - id: integer
 - user_id: integer
 - receive_newsletter: boolean
 - receive_message: boolean

users テーブルや user_settings のカラム数は、
今後機能を追加していく予定なので、さらに増えていくと思います。

また、メール通知の設定だったり、プロフィールの公開範囲の設定だったり、
設定の種類も今後増えていくと考えられます。
さらにユーザーのステータスも管理することになるかもしれません。
そういった場合のテーブル設計についても教えていただけると幸いです。

考えたこと

１つのテーブルに統一した場合、たとえばユーザーのプロフィール更新のとき、
必要のない余計な設定情報をデータベースから取得してしまい、メモリを消費してしまう可能性があります。

ただユーザー情報と設定情報を同時に読み込んだり、更新したりする場合もあるかと思います。
その場合は、join するか、別にデータを読み込む必要あります。

このようにメリットとデメリットどちらも考えられるので、どうするべきか迷っています。
何卒よろしくお願いいたします。

Answer 1

usersに含めるか否かは、その情報が必須かオプショナルかで選択すれば良いでしょう。
必須でない情報をゴテゴテ付けてしまうとNull値だらけのスカスカなテーブルになってしまいます。
例えば、ログイン処理とTOPページの表示に必要な情報だけに絞ってusersに含めるというのも設計の一案でしょう。

必須でない場合、user_settingsテーブルを下記のように作る案もあります。
懸念事項の拡張性にも対応しやすいですし、Null値が多くなるという問題も解消されます。
(user_idとkeyの複合UNIQUEキーで管理すれば良いのでidは不要)

user_settings
- id
- user_id
- key
- value
- modified_at
- created_at

まぁ、valueの型がvar_charしか使えなくなってしまうので表現的には弱いですし、
カラム追加と比べて重複データは多くなるのでファイルサイズも大きくなりますけどね。

---

もしMySQLを5.7に引き上げられる場合、JSON型が使えます。
usersテーブル1個で綺麗に管理出来るでしょう。
もう知ってた？ MySQL 5.7でNoSQLっぽくJSONデータを扱う方法

users
- id: integer (AI)
- email: var_char
- name: var_char
- settings: json
- deleted_at: datetime
- modified_at: datetime
- created_at: datetime

Comments

[gesorein]

ご回答いただきありがとうございます。
その情報が必須かオプショナルかで判断していけば良いのですね。
どのような場合に分割すべきか迷っていたので、参考になりました。

Key, Value形式での設定の方法も教えていただきありがとうございます。
頻繁に設定項目を追加する必要がある場合は、拡張性があるこちらのほうが良いですね。