テーブル設計2

チャプター2で1枚のテーブルを設計しました。この章では複数のテーブルに分ける設計を学習します。前の章でJOINを学習したので、「分けても繋げる」ことをもう知っています。だから今日は安心して分けられます。出発点は、今のordersテーブルが抱えている限界です。

今のordersの限界

現在のordersは、1行が「1人が1商品を買った」記録です。

ここで、現実のECサイトを思い出してください。買い物カゴには複数の商品を入れて、まとめて1回の注文にしますよね。「イヤホン1個とコーヒー豆2袋を、1回の注文で買う」。これを今のordersは表現できません。行を2つに分けると「2回の別々の注文」になってしまい、「同じ注文だった」という情報が消えます(送料の計算も、注文履歴の表示も困ります)。

さて、どう設計しましょうか。よくある失敗案を2つ、先に潰しておきます。

失敗案① 列を増やす

「商品欄を3つ用意すればいい」。動きそうに見えますが、問題だらけです。4つ商品買いたい人が現れたら列を足すのか。ほとんどの注文で後ろの列はNULLだらけ。そして「商品id 4を含む注文」を探すのに、WHEREを3列分書く羽目になります。同じ意味の列に番号をつけて並べたくなったら、設計が間違っているサインです。

失敗案② カンマ区切りで詰める

「1つの列に '1,4' と文字列で詰めればいい」。これも実務で本当に見かける失敗です。product_idsはtext型になるので、数値であることを型が守ってくれません。JOINもできません(ONの突き合わせは値の一致であって、「カンマ区切りの中に含まれる」ではないので)。集計もできません。1つのマスに複数の値を詰めたくなったら、それも設計が間違っているサインです。

正解:行で増やせるように、テーブルを分ける

列でも、マスの中でもなく、行で増やす。そのために「注文そのもの」と「注文の中身」を別のテーブルに分けます。