RDBでセットメニューを表現する方法

はじめに

この記事は新しい技術にチャレンジし続けるpalanのアドベントカレンダーDay22の記事です！
昨日は「figmaでGIFを作成する！」についての記事でした。

FigmaでGIFを作成する！

今回はRDBでセットメニューを表現する方法の記事です。

背景

現在、私はプラハチャレンジという外部サービスで学習をしています。その中で学んだことを社内でも共有したいと思い、今回記事を書くことにしました。

その課題の中でRDBでハンバーガーショップのような単品メニューとセットメニューの注文をどの様に表現するか？というような課題がありました。今回は自分の回答とメンターの人の回答を比べて解説していきます。

自分の回答

私の回答はこちらです。単品メニューとセットメニューを別のテーブルに分けて表現しました。注文も単品メニューとセットメニューを分けているので、単品注文詳細とセット注文詳細を分けています。メニューの表現方法から解説していきます。

メニューの表現方法

メニューの表現方法だけを切り出したものが下記になります。単品メニューとセットメニューのテーブルを分けて考えました。セットメニューにどの単品メニューが含まれているかはセットメニュー詳細テーブルで単品メニューとセットメニューの多対多で表現します。これ以外の方法が思い浮かびませんでした。。。

実際のレコードは下記のようになります。

単品メニューテーブル

セットメニューテーブル

セットメニュー詳細

注文の表現方法

次に注文の表現方法だけを切り出したものが下記になります。単品メニューとセットメニューを分けたので、注文も単品注文詳細とセット注文詳細を分けました。注文詳細を単品メニューかセットメニューのタイプを判断するカラムを作り、外部キーを動的にして1つのテーブルにすることもできますが、ポリモーフィック関連というアンチパターンになるのでやめました。

実際のレコードは下記のようになります。

注文テーブル

単品注文詳細テーブル

セット注文詳細

単品メニューとセットメニューを注文した場合は単品注文詳細とセット注文詳細どちらにもレコードが作成されます。

問題点

集計する時に多くのテーブルを結合しなければならない

単品メニューとセットメニューのハンバーガーの販売個数を集計したい時に全てのテーブルを結合しなければなりません。単品メニューだけの集計は単品メニューだけを結合すれば単品メニューだけの集計ができるので簡単です。

拡張する度に2つ以上のテーブルが増える

将来的に単品メニューやセットメニュー以外のメニューの概念ができた時に新たに注文詳細テーブルも作る必要があります。いい例えが思い浮かばないのですが、おもちゃを販売することになり、単品メニューテーブルとは分けたい場合。おもちゃテーブルとおもちゃ注文詳細テーブルを作る必要があります。

メンターの回答

メンターさんの回答は下記でした。単品メニューもセットメニューもメニューテーブルに保存し、セットメニュー詳細はセットメニューIDと単品メニューIDにメニューIDを入れるという表現方法でした。

実際のレコードは下記のようになります。

メニューテーブル

セットメニュー詳細

同じテーブルの別カラムに同じ外部キーを入れるという表現方法は始めて見ましたが、この表現方法であれば注文詳細も一つのテーブルだけでいいのでスッキリします。
単品メニューとセットメニューの集計もテーブル数が少なくなったため、結合が少なくて済みます。
将来的な拡張も全てのメニューをメニューテーブルに保存するため、メニューテーブルのレコードを増やすだけで、注文詳細テーブルを増やす必要がなさそうです。

問題点

単品メニューでもセットメニューとして表現できてしまう

セットメニュー詳細テーブルのセットメニューIDに単品メニューのIDでも保存できてしまうので、単品メニューなのにセットメニューになってしまう恐れがあります。

まとめ

単品とセットを表現する場合はテーブル数が少なく、拡張するときにもレコードを増やすだけで済みそうなので、メンターさんの方法で試してみたいと思います。

プラハチャレンジで同じ課題でもテーブルの構造が十人十色なのは面白いなぁと日々思っています。自分は受け取った仕様を直感的にテーブルにしてしまうことが多いので、将来的な拡張性やクエリの複雑さなども考慮して検討できるようになりたいです。