一対一関係のテーブル
データベース設計のセオリーとしては、一対一のデータは一つのテーブルにまとめるもの。でも必ずしも、一対一のテーブルを作ってはいけないという訳ではない。どういうケースなら一対一のテーブルが作られるべきなのか。
一対一関係のテーブルが必要な3ケース
1. フィールド数が制限の255を超えてしまうケース
正規化されたテーブルが制限数を超えることは考えにくいですが、ありえないとは言えません。その時は、やむなし。わけるしかない。
2. データ管理の都合上分ける必要があるケース
例えば、同じUserに関する情報でも、機密度合いが高い情報に関しては、他の比較的機密でない情報と一緒に管理するのではなく、わけてアクセス権を絞るなりして管理の仕方を変える。
3.【注目】オブジェクト指向的に扱いやすいケース
これまでの二つのケースは、DB設計上一般的なケースだが、今回伝えたいのはこれ。Rails等でDB設計に基づいたクラスを持つアプリケーションを構築する場合に想定すべきケースが、オブジェクト指向的に扱いやすいかどうか。
わかりやすい例を考えよう。
Boy視点のゲームを考える。Boyオブジェクトに、一対一でGirlFriendが存在するとする。
一対一だしtableまとめて、
Boyオブジェクト
height: ""
weight: ""
career: ""
girlfriend_name: ""
girlfriend_personality: ""
...
みたいに、BoyオブジェクトにDB設計的には、GirlFriend持たせることはできるけど、これ明らかにオブジェクト指向的にイケてないよね。
- いやGirlFriend変わるときにいちいち全部書き換えるのめんどいし
- というか、Boyクラスをmodelで作成したときに、そこにGirlに関するフラグも含まれてるの変だし
Girlに関する情報はGirlオブジェクトに任せて管理したいよね。ということで、Tableをわけることで、Modelクラス自体をわけよう、となる。
わけた際のBoyとGirlのつながりに関しては、絶対に1対1だと仮定するなら、どちらかに相手のid持たせればいい。(もしそもそも1対1以外の関係もあり得ると主張するなら、今回の場合だと中間テーブル作ればよい。それは今回の前提と違うけど。)
1対1関係でもオブジェクト指向的にわけた方が良い(意味的に複数のオブジェクトにわけた方が扱いやすい)場合は、1対1テーブルに分けましょうという話でした。
参考
[1:1テーブル] http://hatenachips.blog34.fc2.com/blog-entry-29.html
[オブジェクト指向] http://tdak.hateblo.jp/entry/20140406/1396773476