データベースの構造、データの持ち方について

Question

現在WEBアプリを開発中ですが、
mysqlのデータの持ち方について悩んでおります。

例えば、web上から商品の登録ができるようなフォームがある場合、
商品テーブルには

商品名	type１	type２	type3
商品A	食品	セット	夏

と登録するしようと思います。

①ここで商品登録フォームのtype1〜type3はselectフォームで選択型にしたいと思っております。
②type1〜type3はそれぞれ、管理画面上で変更追加ができるようにデータベースでデータを持つ
③type1〜type3はそれぞれの値によって変動する動的なフォームではない

そうする場合
タイプテーブルとしてシリアライズして保存した方がいいのか。

type_name	content
type1	a:6:{i:0;s:4:”食品”;i:2;s:4:”雑貨”;i:3;s:6:”消耗品”;}
type2	a:6:{i:0;s:4:”個別”;i:2;s:6:”セット”;i:3;s:6:”まとめ”;}
type3	a:6:{i:0;s:2:”冬”;i:2;s:2:”夏”;i:3;s:2:”春”;}

それぞれのテーブルを持った方がいいのか

type1_no	content
1	食品
2	雑貨
3	消耗品

type2_no	content
1	個別
2	セット
3	まとめ

type3_no	content
1	冬
2	夏
3	春

シリアライズした場合、編集や追加、削除がめんどくさいのかな、でも呼び出しはデータベースの１回で呼び出して配列で回せるな
バラバラにすると編集や追加はやりやすいけど、最低３回はデータベースを呼び出す事になる

などどうすればいいか悩んでいます。王道はこうです！とか長所短所などアドバイスをいただけると助かります。

Answer 1

正規化という単語で調べてみましょう。

他のテーブルに入れるようなデータを、シリアライズ形式でぶっこむようなことは、やむを得ない理由がなければやってはいけません。

Comments

[u-sukesan]

ありがとうございます。
正規化するにあたって、データの追加・更新・削除がしにくいシリアライズ化したデータでぶっ込んで置くことは良くない。

という理解でよろしいでしょうか

[maisumakun]

「シリアライズ化したデータでぶっ込んで置くこと」は正規化とは言いません。非正規型です。

[u-sukesan]

なるほど、シリアライズ化したものを入れておくこと自体、非正規化なんですね
理解しました

Answer 2

私ならこの例で設計すると、合計４つのテーブルを作成することになりそうですね。
以下、簡単な正規化の例です。

・商品テーブル(merchant)
id(int)
name(varchar)
genre_id(int)
unit_type_id(int)
season_id(int)

・ジャンルテーブル(genre)
id(int)
name(varchar)

・単位テーブル(unit_type)
id(int)
name(varchar)

・季節テーブル(season)
id(int)
name(varchar)

商品情報を取得するときは以下のようなJOINのクエリを用いれば、1回の呼び出しでOKです。
SELECT merchant.name,genre.name,unit_type.name,season.name FROM merchant
LEFT JOIN genre ON merchant.genre_id = genre.id
LEFT JOIN unit_type ON merchant.unit_type_id = unit_type.id
LEFT JOIN season ON merchant.season_id = season.id;

それぞれで名称に変更があった場合も、対応するテーブルのnameを修正すればOKですね。
シリアライズして持っている場合、全商品データを抽出して変更したいデータを含む商品だけを抽出して全部更新する必要が出てきます。
さらに、「食品」に属する商品だけを抽出したい...といった場合、シリアライズして格納されている場合、「食品」というキーワードでLIKE検索するしかなさそうです。（LIKE検索はとても遅い検索なので可能な限り避けたいところ）
上記のような設計であれば、下記のようにジャンルIDを指定した検索で素早く該当商品の一覧を取得できます。
SELECT * FROM merchant WHERE genre_id = 1;

このようなテーブルを設けることで登録画面のフォームを作成する際も、たとえば季節の入力欄はseasonsテーブルの内容を選択肢として表示するようにしておけば、今後追加があればseasonテーブルにデータを追加すれば済みます。
（たとえば季節で「秋冬商品」とか？）

また、テーブル名やカラム名は「TYPE_xx」といった抽象的な単語は使用せず、名前から内容を想像できるものにできればいいですね。

他にもシリアライズだとデータ量が増えたりします。

クエリはJOINする必要があり多少面倒にも感じられるかもしれませんが、正規化してテーブルを分割することをお勧めします。

Comments

[u-sukesan]

ご丁寧な説明ありがとうございいます。
参考になりました。

そうなんです。テーブルを分けること、JOINする負荷など考えると、シリアライズがいいのかなぁなど考えると迷ってしまいます。

頂いた内容と同じような方向で検討しています。

[Yith]

JOINが面倒だから非正規化するのはやめた方がいい場合がほとんどです。
非正規化でいくと今は良くても、後から仕様変更に迫られた場合などに対応に困ることになりがちです。
正規化→非正規化を検討するのは、どうしても正規化してJOINが走るとパフォーマンス的に問題がでる場合ぐらいにしておく方が良いと考えています。
この辺はデータ量やサーバースペックに依存しますが、私の経験ではJOINで困ったことは（めったに）ありません。
インデックスがしっかりしていれば、単純なJOINでパフォーマンスが問題になるケースは少ないと思います。
ただし、インデックス大事です！
JOINだけでなく、SQLのパフォーマンス出ないときは、まずインデックス見直してくださいね。