【カテゴリのジレンマとは】
カテゴリのジレンマとは、あるものに関連付ける「カテゴリ」が存在する。
その「カテゴリ」をユーザが追加でき、「カテゴリ」がネストする（階層化できる）場合の
DB設計をした際に生じる問題。
今回のテーマ
今回は、
食べ物テーブル と カテゴリテーブル
の カテゴリのジレンマ について考える。
DBイメージ
食べ物テーブル と カテゴリテーブル
のDBイメージは以下の通りである。
カテゴリテーブル登録イメージ
カテゴリテーブル
の登録イメージは以下の通りである。
食べ物テーブル登録イメージ
食べ物テーブル
の登録イメージは以下の通りである。
【考察①】とりあえず表のようにDBを作る
DBを表のように作ります。
カテゴリ登録を行うと・・・
カテゴリ登録を行うとなぜか「カテゴリテーブル」のようにDB登録されます！！
（1つずつ登録しているので当たり前）
え？一括登録すればいいって？
カテゴリ登録を一括で行ったとしても
正規化されていないDBは見るに堪えない・・・。
（毎回「和食」を登録するのか・・・）
【考察②】カテゴリ毎にテーブルを分ける
カテゴリを正規化して、DBを表のように作ります。
食べ物登録を行うと・・・
何を選んでもカテゴリが全表示されるバグが発生。
（カテゴリテーブル間の関係が決まっていないため）
カテゴリテーブル間に関係を作ると・・・
ねじれ過ぎてて読み解きにくい・・・
（もう少しシンプルに設計したい・・・）
【考察③】カテゴリまとめテーブルを作る
正規化したカテゴリテーブルに
カテゴリをまとめる「カテゴリまとめテーブル」を追加する。
デジャブ！？・・・
DBを表の通り作成したときと同じことが起こります。
また、一括登録では途中で登録をやめた際に
そこまでのデータが残らないのがネックです。
【考察④】カテゴリに親子関係を作る
カテゴリに親子関係を追加して、DBを表のように作ります。
カテゴリ登録を行うと・・・
親カテゴリIDで制御されているので、
不要なカテゴリは表示されません！！
食べ物登録を行うと・・・
イメージ通りカテゴリが表示されます。
しかし、1つのテーブルで3テーブル分管理
しているようなものなのでDBの肥大化が怖い・・・
最後に
以上、DB設計時のカテゴリのジレンマでした！
カテゴリを考えるだけで
こんなに発想が出てくるなんて
面白いですよね。
もし、より効率的にカテゴリ管理をする方法を
ご存知の方がいましたらコメントお願いします。