レストラン配信データモデル

お腹が空いたけど料理したくない？レストランを呼び出し、お気に入りの食事を注文し、プロセス全体を整理できるデータモデルについて読んでください。

「時間節約」技術は豊富にありますが、食事などの基本的なニーズを満たす時間は少ないようです。何かを食べたいが、自分で料理する時間（またはスキル）がない場合は、レストランに食べ物を注文することができます（つまり、テイクアウトまたはテイクアウト）。これにより、食事がすぐに届きます。もちろん、私たちはこの便利さのためにお金を払わなければならないので、私たちは食べ物がおいしくて暑いことを期待しています！

明らかに、どのレストランも顧客を満足させ続けるために動機付けられています。テイクアウトの実行にどれだけの作業が必要かを知って驚くかもしれません。ほとんどの場合、注文と配送を管理するために何らかの追跡システムを使用しています。そのようなシステムの1つの下にあるデータモデルを見てみましょう。おやつを食べて、座って、記事を楽しんでください。

レストラン事業について知っておくべきこと

食べ物を作って顧客に届けるのは簡単ではありません。まず第一に、あなたはおいしい食事を準備するための才能と知識を持っている必要があります。また、整理する必要があります。これらの食事が時間どおりに適切な場所に配達される場合は、すべてが完全に機能する必要があります。

食事の提供を開始する前に、次のことを知っておく必要があります。

食事を注文した人
食事をいつどこに配達するか
注文に含まれる料理
注文を処理するために必要な材料
注文がすでに支払われている場合

また、配達状況を追跡し、食事や配達プロセスに関する顧客のフィードバックを記録する必要があります。さらに、どの食事が最も（または最も）人気がないかを知りたいかもしれません。また、レポートと分析の目的で、財務情報も保持する必要があります。

顧客が配達の注文を行うために使用できるアプリがあると仮定しましょう。それは彼らがメニュー項目を選び、それらの代金を払い、そして配達時間と住所を指定することを可能にします。そのようなアプリの下にあるデータモデルはどのように見えるでしょうか？

データモデル

Edit model in your browserをクリックすると、このモデルをブラウザで開くことができますボタン。

データモデルは、次の3つのサブジェクト領域で構成されています。

Restaurants & customers
Menus
Orders

各サブジェクトエリアは、リストされている順序で表示されます。

レストランと顧客

Restaurants & customers サブジェクトエリアには、レストラン（複数ある場合もあります）、営業している都市、および顧客に関する詳細を格納する3つのテーブルが含まれています。

顧客とレストランの両方が都市（または町、村など）にあります。したがって、city 辞書。 city_nameの2つの属性のみが含まれていますおよびzip_code 。複数の国で事業を行っている場合は、この表に関連する国の辞書も必要になりますが、ここでは取り上げません。

次に、私たちが運営するすべてのレストランのリストが必要です。 restaurant そのためのテーブル。わかりやすくするために、各レストランのaddressのみを保存しますおよびcity それが置かれている場所。

このサブジェクトエリアの最後のテーブルは、customer テーブル。ここには、登録されているすべての配達顧客のリストが保存されます。この表のデータを使用して、モデルの後半で顧客を注文にリンクします。もちろん、注文するために顧客をモデルに登録する必要はありませんが、それでもこのリストは必要です。ロイヤルティプログラムとして、登録済みのお客様に割引を提供することができます。または、このデータを使用して、特別オファーで顧客に連絡することもできます。登録された顧客ごとに、以下を保存します：

customer_name –顧客のフルネーム。
city_id – city 顧客が住んでいる場所。
address –顧客の住所。
contact_phone –顧客の電話番号。
email –登録プロセス中に顧客が使用したメールアドレス。
confirmation_code –登録プロセス中に使用される確認コード。
password –このアプリ用に顧客が選択したパスワード。
time_joined –顧客がアプリケーションに参加したときのタイムスタンプ。

メニュー

このサブジェクトエリアには、レストランのメニューに関する情報が含まれています。今のところ、すべてのレストランが同じメニューを使用していると仮定しましょう。

最初のテーブルはcategory 辞書。これには、category_nameという1つのUNIQUE属性のみが含まれます。。このフィールドには、「飲み物」、「スターター」、「サラダ」、「サンドイッチ」、「ピザ」などの通常のメニューカテゴリが含まれている可能性があります。

次に、menu_item テーブル。メニューのいずれかにある（または持っていた）すべてのアイテムが一覧表示されます。アイテムごとに、以下を保存します：

item_name –そのアイテムの名前。例：「チキンサンドイッチ」。
category_id –category アイテムが属すること、例えば「サンドイッチ」。
description –そのアイテムの説明。これは、印刷されたメニューと同じである必要があります。
ingredients –そのアイテムを生産するために使用される材料とその量。このフィールドには実際にレシピを保存できます。
price – 1つのアイテムの現在の価格（例：チキンサンドイッチ1つ）。
active –アイテムが現在のメニューで提供されている場合。

メニューを複数の言語で保存する場合は、この記事で紹介するようなアプローチを使用する必要があります。

ほとんどのレストランには、特別な期間限定のオファーがあります。彼らはまた、無制限の時間のいくつかのオファーを持っているかもしれません。 offer これらのテーブル。それぞれについて、次のようになります。

date_active_from およびdate_active_to –一緒に、これらはこのオファーがいつアクティブになるかを定義します。オファーの期間が無制限の場合、またはオファーが日数ではなく時間に基づいている場合、これら2つの属性にはNULL値が含まれます。このタイプのオファーの例は、「3月中に、カレーを1つ購入すると、50％オフになる」です。
time_active_from およびtime_active_to –オファーが有効な時刻を定義します–例：「毎日午前6時から9時まで無料のコーヒーを飲みましょう。」
offer_price –そのオファーの価格。

オファーに含まれるすべてのメニュー項目は、in_offer テーブル。このテーブルには、offer_idのUNIQUEペアが含まれています – menu_item_id 。

レストランのメニューが異なる場合は、レストランごとに個別のメニューを作成する必要があります。次に、メニューとオファーを外部キーを使用するレストランと関連付ける必要があります。これにより、他のレストランに影響を与えることなく、どのレストランのメニューやオファーも変更できるようになります。これはデータベースを複雑にするだけではありません。ビジネスモデルもより複雑になります。これが、ほとんどのレストランチェーンが1つのメニューだけに固執する理由であり、このモデルではこの方法を使用しないことにした理由です。

注文

モデルの最後のサブジェクト領域はOrdersですサブジェクトエリア。ここに、注文とそのステータスを保存するために必要なすべてのものがあります。

ここでの中心的なテーブルはplaced_order テーブル。このテーブルの名前として「order」だけを使用しないことをお勧めします。「order」はSQLキーワードです。テーブルと列の名前としてキーワードを使用しないようにしてください。そうしないと、クエリの作成時にエラーが発生する可能性があります。注文ごとに、以下を記録します：

restaurant_id –restaurant その注文に関連しています。
order_time –注文が行われたときのタイムスタンプ。
estimated_delivery_time –この注文の予定された配信のタイムスタンプ。
food_ready –注文アイテムがいつ準備されたかを示すタイムスタンプ。食品が準備されるまで、これにはNULL値が含まれます。この属性を使用して、注文が出された瞬間と料理が準備された瞬間との間の時間差を計算できます。また、これを使用して、食品の準備ができてから配達されるまでの経過時間を調べることもできます。この情報は、スタッフの効率を高める上で非常に役立ちます。
actual_delivery_time –この注文が実際に配信されたときのタイムスタンプ。食品が顧客に配達されるまではNULLになります。
delivery_address –注文の配送先住所。
customer_id –customer その注文をした人。登録済みのアプリユーザーではない人が注文した場合、この属性にはNULL値が含まれる可能性があります。
price –その注文に含まれるすべてのアイテムの価格。
discount –価格に適用される割引額（クーポンやロイヤルティ割引など）。
final_price –注文価格から割引を差し引いたもの。
comment –注文時に顧客が挿入した追加のコメント。これは、追加の配送手順や、お客様が重要だと思うその他のものである可能性があります。
ts –このレコードがテーブルに挿入されたときのタイムスタンプ。

in_order 表には、注文に含まれるすべてのアイテムまたは特別オファーが一覧表示されます。この表のレコードごとに、以下を保存します：

placed_order_id –関連するorder 。
offer_id –offer 表。ただし、1つ以上のオファーがこの順序に含まれている場合のみ。その場合、menu_item_id 属性はNULLになります。
menu_item_id – menu_item 表。ただし、このレコードがメニュー項目に関連しており、オファーに関連していない場合に限ります。
quantity –この注文に含まれるオファーまたはメニューアイテムの数。
item_price –単一のオファーまたはメニューアイテムの価格。
price –この行の合計価格。item_priceで表されます。 *quantity 。
comment –その注文アイテムに特に関連する、顧客によって挿入されたコメント。「ピザを8枚に切ってください」

comment 表を使用すると、注文に関連する複数のコメントの挿入をサポートできます。コメントごとに、関連する注文のIDと顧客のIDを保存します。このコメントが入力されたときのタイムスタンプも保存されます。また、このコメントが苦情なのか褒め言葉なのかをマークします。一度に設定できるのは、この2つのうちの1つだけです。何も設定されていない場合は、このコメントをニュートラルとして扱います。

モデルの最後の2つのテーブルは、注文に割り当てるステータスに関連しています。 status_catalog テーブルには、すべての可能なUNIQUE status_nameのリストが含まれています注文に割り当てることができる属性。 order_status テーブルには、注文に割り当てられているすべてのステータスが含まれています。このテーブルの各レコードについて、注文とステータスに関連する外部キーと、このステータスが割り当てられたときのタイムスタンプを保存します。

レストランの配達データモデルについてどう思いますか？

今日は、レストランの配達注文を整理、管理、保存するために使用できるデータモデルについて説明しました。各注文のステータスと財務の詳細の一部を追跡できます。このモデルをより堅牢にする方法についていくつかアイデアがありますが、ご意見をお聞かせいただければ幸いです。コメントセクションで共有してください！