MySQLでレストラン注文システムのデータベースを設計するためのガイド

このチュートリアルでは、ユーザー、テーブルの予約、メニュー、在庫、注文、および支払いを管理するためのレストラン注文システムのデータベーススキーマを設計するための完全な手順を提供します。これは、レストランの食品注文を管理するための食品注文データベース設計を提供します。さらに、オンプレミスのレストラン注文システムアプリケーションの開発にも使用できます。

このような注文システムは、注文処理を自動化し、注文のピーク時間を効率的に処理するために実装されているため、少ない労力で顧客満足度が向上します。これは、レストランビジネスにとって双方にメリットのある状況です。

実体関連図または視覚的なデータベース設計を以下に示します。

レストラン注文システム

メモ：テーブルのオンライン予約やレストラン到着前の事前注文にご利用いただけます。このセキュリティは、MySQLでRBACデータベースをフォローすることでも処理できます。

また、UbuntuにMySQL 8をインストールする方法、WindowsにMySQL 8をインストールする方法、Windows10にWorkbenchを使用してMySQL8をインストールする方法、MySqlのRBACデータベース、MySqlのブログデータベース、MySQLのクイズデータベースなどの人気のあるチュートリアルにアクセスすることもできます。 MySQLのポーリングおよび調査データベース、オンラインショッピングカートデータベース、およびMySQLの基本的なSQLクエリを学習します。

レストランデータベース

最初のステップは、レストランデータベースを作成することです。以下に示すクエリを使用して作成できます。

CREATE SCHEMA `restaurant` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

文字セットutf8mb4を使用しました幅広いキャラクターをサポートします。

ユーザーテーブル

このセクションでは、ユーザーテーブルを設計しますユーザー情報を保存します。同じテーブルを使用して、管理者、シェフ、エージェント、顧客など、さまざまなタイプのユーザーを管理できます。これを使用して、ユーザーをメニュー、アイテム、テーブル予約、および注文に関連付けることができます。ユーザーは自分のテーブルと注文を追跡できます。以下は、ユーザーテーブルのすべての列の説明です。

Id 名ミドルネーム姓モバイルメールパスワードハッシュ管理者ベンダーシェフエージェント登録場所最終ログインはじめにプロフィール

ユーザーを識別するための一意のID。

ユーザーの名。

ユーザーのミドルネーム。

ユーザーの名前。

ユーザーの携帯電話番号。ログインと登録の目的で使用できます。

ユーザーのメールアドレス。ログインと登録の目的で使用できます。

適切なアルゴリズムによって生成されたパスワードハッシュ。プレーンなパスワードや暗号化されたパスワードの保存は避けなければなりません。

ユーザーが管理者であるかどうかを識別するフラグ。 RBACデータベースの設計に従ってRBACテーブルを作成する場合は、必須ではありません。

ユーザーが在庫注文を受け取ることができるかどうかを識別するフラグ。 RBACデータベースの設計に従ってRBACテーブルを作成する場合は、必須ではありません。

ユーザーがアイテムを調理できるかどうかを識別するフラグ。 RBACデータベースの設計に従ってRBACテーブルを作成する場合は、必須ではありません。

ユーザーがテーブルをホストできるかどうかを識別するフラグ。 RBACデータベースの設計に従ってRBACテーブルを作成する場合は、必須ではありません。

この列は、アプリケーションを使用しているユーザーの寿命を計算するために使用できます。

ユーザーの最後のログインを識別するために使用できます。

製品ページに表示されるベンダーユーザーの簡単な紹介。

製品ページに表示されるベンダーの詳細。

適切な制約のあるユーザーテーブルは次のとおりです。

CREATE TABLE `restaurant`.`user` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `firstName` VARCHAR(50) NULL DEFAULT NULL,
  `middleName` VARCHAR(50) NULL DEFAULT NULL,
  `lastName` VARCHAR(50) NULL DEFAULT NULL,
  `mobile` VARCHAR(15) NULL,
  `email` VARCHAR(50) NULL,
  `passwordHash` VARCHAR(32) NOT NULL,
  `admin` TINYINT(1) NOT NULL DEFAULT 0,
  `vendor` TINYINT(1) NOT NULL DEFAULT 0,
  `chef` TINYINT(1) NOT NULL DEFAULT 0,
  `agent` TINYINT(1) NOT NULL DEFAULT 0,
  `registeredAt` DATETIME NOT NULL,
  `lastLogin` DATETIME NULL DEFAULT NULL,
  `intro` TINYTEXT NULL DEFAULT NULL,
  `profile` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_mobile` (`mobile` ASC),
  UNIQUE INDEX `uq_email` (`email` ASC) );

材料、アイテム、レシピ、メニューテーブル

このセクションでは、材料、アイテム、レシピ、メニューテーブルを設計します。メニューとアイテムのデータを保存します。

以下は、成分表のすべての列の説明です。。材料テーブルは、在庫を補充するために材料を供給できるサプライヤーを識別するためにもマップされます。より高度なシナリオでは、同じ材料の複数のサプライヤをサポートするために、材料とサプライヤの関係を格納するための個別のテーブルが存在する場合があります。

Id ユーザーID ベンダーID タイトルスラッグ概要タイプ SKU 数量単位作成場所更新日コンテンツ

成分を識別するための一意のID。

管理者を識別するためのユーザーID。

サプライヤーを識別するためのベンダーID。

アイテムレシピに表示される材料のタイトル。

材料のGIDとして使用されるユニークなスラッグ。

主なハイライトに言及する要約。

さまざまな成分タイプを区別するためのタイプ。

原料在庫を追跡するための在庫管理ユニット。

材料の利用可能な量。

材料に割り当てられた測定単位。

材料が作成された日時を保存します。

材料が更新された日時を保存します。

材料の追加の詳細を保存するために使用される列。

列の数量と単位を使用して、原料在庫で利用可能な在庫を追跡します。適切な制約のある成分表は以下のとおりです。

CREATE TABLE `restaurant`.`ingredient` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NOT NULL,
  `vendorId` BIGINT DEFAULT NULL,
  `title` VARCHAR(75) NOT NULL,
  `slug` VARCHAR(100) NOT NULL,
  `summary` TINYTEXT NULL,
  `type` SMALLINT(6) NOT NULL DEFAULT 0,
  `sku` VARCHAR(100) NOT NULL,
  `quantity` FLOAT NOT NULL DEFAULT 0,
  `unit` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_slug` (`slug` ASC),
  INDEX `idx_ingredient_user` (`userId` ASC),
  CONSTRAINT `fk_ingredient_user`
    FOREIGN KEY (`userId`)
    REFERENCES `restaurant`.`user` (`id`)
    ON DELETE RESTRICT
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`ingredient`
ADD INDEX `idx_ingredient_vendor` (`vendorId` ASC);
ALTER TABLE `restaurant`.`ingredient` 
ADD CONSTRAINT `fk_ingredient_vendor`
  FOREIGN KEY (`vendorId`)
  REFERENCES `restaurant`.`user` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

以下は、アイテムテーブルのすべての列の説明です。。アイテムテーブルは、非調理アイテムを供給して在庫を補充できるサプライヤを識別するためにもマップされます。より高度なシナリオでは、同じアイテムの複数のサプライヤをサポートするために、アイテムとサプライヤの関係を格納するための個別のテーブルが存在する場合があります。

メモ：同じテーブルを使用して食材やアイテムを保管し、レストランやサプライヤーの注文を簡素化することもできます。このような場合、アイテムの成分を識別するために自己結合が必要です。また、列の調理と価格は材料の行には役立ちません。

Id ユーザーID ベンダーID タイトルスラッグ概要タイプ料理 SKU 価格数量単位レシピ手順作成場所更新日コンテンツ

アイテムを識別するための一意のID。

管理者を識別するためのユーザーID。

サプライヤーを識別するためのベンダーID。

メニューに表示されるアイテムのタイトル。

アイテムのGIDとして使用される一意のスラッグ。

主なハイライトに言及する要約。

異なるアイテムタイプを区別するためのタイプ。

アイテムに調理が必要かどうかを識別するフラグ。

アイテムの在庫を追跡するための在庫管理ユニット。アイテムが材料に関連付けられていない場合にのみ必要です。

1ユニットまたは1サービングの販売価格。

アイテムの利用可能な数量。アイテムが材料に関連付けられていない場合にのみ必要です。

アイテムに割り当てられた測定単位。アイテムが材料に関連付けられていない場合にのみ必要です。

アイテムを調理するために必要な手順。

アイテムを提供するために必要な手順。

アイテムが作成された日時を保存します。

アイテムが更新された日時が保存されます。

アイテムの追加の詳細を保存するために使用される列。

材料テーブルと同様に、列の数量と単位を使用して、アイテムの在庫で利用可能な在庫を追跡します。適切な制約のあるアイテムテーブルは次のとおりです。

CREATE TABLE `restaurant`.`item` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NOT NULL,
  `vendorId` BIGINT DEFAULT NULL,
  `title` VARCHAR(75) NOT NULL,
  `slug` VARCHAR(100) NOT NULL,
  `summary` TINYTEXT NULL,
  `type` SMALLINT(6) NOT NULL DEFAULT 0,
  `cooking` TINYINT(1) NOT NULL DEFAULT 0,
  `sku` VARCHAR(100) NOT NULL,
  `price` FLOAT NOT NULL DEFAULT 0,
  `quantity` FLOAT NOT NULL DEFAULT 0,
  `unit` SMALLINT(6) NOT NULL DEFAULT 0,
  `recipe` TEXT NULL DEFAULT NULL,
  `instructions` TEXT NULL DEFAULT NULL,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_slug` (`slug` ASC),
  INDEX `idx_item_user` (`userId` ASC),
  CONSTRAINT `fk_item_user`
    FOREIGN KEY (`userId`)
    REFERENCES `restaurant`.`user` (`id`)
    ON DELETE RESTRICT
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`item`
ADD INDEX `idx_item_vendor` (`vendorId` ASC);
ALTER TABLE `restaurant`.`item` 
ADD CONSTRAINT `fk_item_vendor`
  FOREIGN KEY (`vendorId`)
  REFERENCES `restaurant`.`user` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

レシピテーブル 1食分のアイテムに必要な材料の量を追跡するために使用できます。以下は、レシピテーブルのすべての列の説明です。

Id アイテムID 材料ID 数量単位手順

レシピを識別するための一意のID。

アイテムを識別するためのアイテムID。

材料を識別するための材料ID。

1回のサービングでアイテムを調理するために必要な材料の量。

アイテムに必要な材料の量を特定するための測定単位。

アイテムを調理するために必要な材料の説明。

適切な制約のあるレシピテーブルは次のとおりです。

CREATE TABLE `restaurant`.`recipe` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `itemId` BIGINT NOT NULL,
  `ingredientId` BIGINT NOT NULL,
  `quantity` FLOAT NOT NULL DEFAULT 0,
  `unit` SMALLINT(6) NOT NULL DEFAULT 0,
  `instructions` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_recipe_item` (`itemId` ASC),
  UNIQUE INDEX `uq_recipe_item_ingredient` (`itemId` ASC, `ingredientId` ASC),
  CONSTRAINT `fk_recipe_item`
    FOREIGN KEY (`itemId`)
    REFERENCES `restaurant`.`item` (`id`)
    ON DELETE RESTRICT
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

ALTER TABLE `restaurant`.`recipe`
ADD INDEX `idx_recipe_ingredient` (`ingredientId` ASC);
ALTER TABLE `restaurant`.`recipe` 
ADD CONSTRAINT `fk_recipe_ingredient`
  FOREIGN KEY (`ingredientId`)
  REFERENCES `restaurant`.`ingredient` (`id`)
  ON DELETE RESTRICT
  ON UPDATE NO ACTION;

以下は、メニューテーブルのすべての列の説明です。。メニューテーブルを使用して、同じレストランの複数のメニューを保存できます。

Id ユーザーID タイトルスラッグ概要タイプ作成場所更新日コンテンツ

メニューを識別するための一意のID。

管理者を識別するためのユーザーID。

メニューカードに表示されるメニュータイトル。

メニューのGIDとして使用される一意のスラッグ。

メニューカードの主なハイライトに言及する要約。

さまざまなメニュータイプを区別するためのタイプ。

アイテムが作成された日時を保存します。

アイテムが更新された日時が保存されます。

メニューの追加の詳細を格納するために使用される列。

適切な制約のあるメニューテーブルは次のとおりです。

CREATE TABLE `restaurant`.`menu` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NOT NULL,
  `title` VARCHAR(75) NOT NULL,
  `slug` VARCHAR(100) NOT NULL,
  `summary` TINYTEXT NULL,
  `type` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_slug` (`slug` ASC),
  INDEX `idx_menu_user` (`userId` ASC),
  CONSTRAINT `fk_menu_user`
    FOREIGN KEY (`userId`)
    REFERENCES `restaurant`.`user` (`id`)
    ON DELETE RESTRICT
    ON UPDATE NO ACTION);

メニュー項目テーブル メニューカードで利用可能なアイテムを追跡するために使用できます。以下は、メニュー項目テーブルのすべての列の説明です。

Id メニューID アイテムID アクティブ

メニュー項目を識別するための一意のID。

メニューを識別するためのメニューID。

アイテムを識別するためのアイテムID。

アイテムが利用可能かどうかを確認するためのフラグ。

適切な制約のあるメニュー項目テーブルは次のとおりです。

CREATE TABLE `restaurant`.`menu_item` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `menuId` BIGINT NOT NULL,
  `itemId` BIGINT NOT NULL,
  `active` TINYINT(1) NOT NULL DEFAULT 1,
  PRIMARY KEY (`id`),
  INDEX `idx_menu_item_menu` (`menuId` ASC),
  UNIQUE INDEX `uq_menu_item` (`menuId` ASC, `itemId` ASC),
  CONSTRAINT `fk_menu_item_menu`
    FOREIGN KEY (`menuId`)
    REFERENCES `restaurant`.`menu` (`id`)
    ON DELETE RESTRICT
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

ALTER TABLE `restaurant`.`menu_item`
ADD INDEX `idx_menu_item_item` (`itemId` ASC);
ALTER TABLE `restaurant`.`menu_item` 
ADD CONSTRAINT `fk_menu_item_item`
  FOREIGN KEY (`itemId`)
  REFERENCES `restaurant`.`item` (`id`)
  ON DELETE RESTRICT
  ON UPDATE NO ACTION;

アイテムシェフテーブル アイテムを調理するために割り当てられたシェフを識別するために使用できます。以下は、アイテムシェフテーブルのすべての列の説明です。

Id アイテムID シェフID アクティブ

メニュー項目を識別するための一意のID。

アイテムを識別するためのアイテムID。

ユーザーを識別するためのシェフID。

シェフがアイテムを調理できるかどうかを確認するためのフラグ。

適切な制約のあるアイテムシェフテーブルは次のとおりです。

CREATE TABLE `restaurant`.`item_chef` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `itemId` BIGINT NOT NULL,
  `chefId` BIGINT NOT NULL,
  `active` TINYINT(1) NOT NULL DEFAULT 1,
  PRIMARY KEY (`id`),
  INDEX `idx_item_chef_item` (`itemId` ASC),
  UNIQUE INDEX `uq_item_chef` (`itemId` ASC, `chefId` ASC),
  CONSTRAINT `fk_item_chef_item`
    FOREIGN KEY (`itemId`)
    REFERENCES `restaurant`.`item` (`id`)
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

ALTER TABLE `restaurant`.`item_chef`
ADD INDEX `idx_item_chef_chef` (`chefId` ASC);
ALTER TABLE `restaurant`.`item_chef` 
ADD CONSTRAINT `fk_item_chef_chef`
  FOREIGN KEY (`chefId`)
  REFERENCES `restaurant`.`user` (`id`)
  ON DELETE CASCADE
  ON UPDATE NO ACTION;

テーブルトップと予約テーブル

このセクションでは、テーブルトップと予約テーブルを設計します。レストランのテーブルとその予約の詳細を保存します。

テーブルトップテーブル レストランのテーブルの詳細を保存するために使用できます。テーブルのステータスは、Free、Reserved、およびActiveにすることができます。 MySQLのtableキーワードと区別するために、Tableの代わりにTableTopを使用しました。以下は、TableTopテーブルのすべての列の説明です。

Id コードステータス容量作成場所更新日コンテンツ

テーブルを識別するための一意のID。

テーブルコード。

レビューの評価。

テーブルの総座席数。

テーブルが作成された日時を保存します。

テーブルが更新された日時を保存します。

テーブルの追加の詳細を格納するために使用される列。

適切な制約のあるTableTopテーブルは次のとおりです。

CREATE TABLE `restaurant`.`table_top` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `code` VARCHAR(100) NOT NULL,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `capacity` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`));

予約テーブル オンラインまたはオンプレミスでレストランのテーブルを予約するために使用できます。ログインしたユーザーまたは既存のユーザーも予約に関連付けることができます。また、ステータスがFreeのテーブルのみを予約できることを前提としています。予約確認後、テーブルの状態を予約済みに変更することができます。また、ゲストがテーブルを占有するとすぐに、テーブルのステータスをアクティブに設定できます。以下は、予約テーブルのすべての列の説明です。

メモ：予約テーブルは、テーブルの予約に関連する支払いをカバーしていません。テーブルの予約に関連する支払いを処理する列を追加することで、さらに更新できます。

Id テーブルID ユーザーID トークンステータス名ミドルネーム姓モバイルメール 1行目 2行目都市州国作成場所更新日コンテンツ

予約を識別するための一意のID。

予約に関連付けられているテーブルを識別するためのテーブルID。

予約に関連付けられた登録ユーザーを識別するためのユーザーID。

予約に関連付けられた一意のトークン。

予約のステータスは、[新規]、[ラウンジ]、[アクティブ]、[完了]のいずれかになります。

ゲストの名。

ゲストのミドルネーム。

ユーザーの名前。

ユーザーの携帯電話番号。

ユーザーのメールアドレス。

住所を保存する最初の行。

住所を保存する2行目。

住所の都市。

住所の州。

住所の国。

予約が作成された日時が保存されます。

予約が更新された日時が保存されます。

予約の追加の詳細を保存するために使用される列。

適切な制約のある予約テーブルは次のとおりです。

CREATE TABLE `restaurant`.`booking` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `tableId` BIGINT NOT NULL,
  `userId` BIGINT NULL DEFAULT NULL,
  `token` VARCHAR(100) NOT NULL,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `firstName` VARCHAR(50) NULL DEFAULT NULL,
  `middleName` VARCHAR(50) NULL DEFAULT NULL,
  `lastName` VARCHAR(50) NULL DEFAULT NULL,
  `mobile` VARCHAR(15) NULL,
  `email` VARCHAR(50) NULL,
  `line1` VARCHAR(50) NULL DEFAULT NULL,
  `line2` VARCHAR(50) NULL DEFAULT NULL,
  `city` VARCHAR(50) NULL DEFAULT NULL,
  `province` VARCHAR(50) NULL DEFAULT NULL,
  `country` VARCHAR(50) NULL DEFAULT NULL,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_booking_table` (`tableId` ASC),
  CONSTRAINT `fk_booking_table`
    FOREIGN KEY (`tableId`)
    REFERENCES `restaurant`.`table_top` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`booking`
ADD INDEX `idx_booking_user` (`userId` ASC);
ALTER TABLE `restaurant`.`booking` 
ADD CONSTRAINT `fk_booking_user`
  FOREIGN KEY (`userId`)
  REFERENCES `restaurant`.`user` (`id`)
  ON DELETE CASCADE
  ON UPDATE NO ACTION;

予約アイテムテーブル ゲストが注文したアイテムを追跡するために必要です。以下は、予約アイテムテーブルのすべての列の説明です。

Id 予約ID アイテムID SKU 価格割引数量単位ステータス作成場所更新日コンテンツ

予約アイテムを識別するための一意のID。

予約アイテムに関連付けられている予約を識別するための予約ID。

予約アイテムに関連付けられているアイテムを識別するためのアイテムID。

注文時のアイテムのSKU。

注文時の商品の販売価格。

注文時のアイテムの割引。

ユーザーが注文したアイテムの数量。アイテムユニットの乗数またはシングルサービングのいずれかになります。

アイテムの注文時の測定単位。

アイテムの進行状況を追跡するためのステータス。 New、Kitchen、Cooking、Cooked、Servedのいずれでもかまいません。

予約アイテムが作成された日時が保存されます。

予約アイテムが更新された日時が保存されます。

予約アイテムの追加の詳細を保存するために使用される列。

適切な制約のある予約アイテムテーブルは次のとおりです。

CREATE TABLE `restaurant`.`booking_item` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `bookingId` BIGINT NOT NULL,
  `itemId` BIGINT NOT NULL,
  `sku` VARCHAR(100) NOT NULL,
  `price` FLOAT NOT NULL DEFAULT 0,
  `discount` FLOAT NOT NULL DEFAULT 0,
  `quantity` FLOAT NOT NULL DEFAULT 0,
  `unit` SMALLINT(6) NOT NULL DEFAULT 0,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_booking_item_booking` (`bookingId` ASC),
  CONSTRAINT `fk_booking_item_booking`
    FOREIGN KEY (`bookingId`)
    REFERENCES `restaurant`.`booking` (`id`)
    ON DELETE RESTRICT
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`booking_item` 
ADD INDEX `idx_booking_item_item` (`itemId` ASC);
ALTER TABLE `restaurant`.`booking_item` 
ADD CONSTRAINT `fk_booking_item_item`
  FOREIGN KEY (`itemId`)
  REFERENCES `restaurant`.`item` (`id`)
  ON DELETE RESTRICT
  ON UPDATE NO ACTION;

注文テーブルと注文アイテムテーブル

このセクションでは、注文を管理するためのテーブルを提供します。ログインしたユーザーを注文に関連付けることもできます。注文テーブルを使用して、完了した予約とベンダー注文を保存できます。ベンダーの注文ステータスは、注文時に新規に設定でき、ベンダーからアイテムを受け取った後に完了に設定できます。また、ベンダーからアイテムを受け取った後、アイテムの価格を手動で入力する必要があります。以下は、注文テーブルのすべての列の説明です。

Id ユーザーID ベンダーID トークンステータス小計アイテムの割引税金配送合計プロモーション割引総計名ミドルネーム姓モバイルメール 1行目 2行目都市州国作成場所更新日コンテンツ

注文を識別するための一意のID。

注文に関連付けられたゲストを識別するためのユーザーID。

注文に関連付けられているベンダーを識別するベンダーID。

注文に関連付けられた一意のトークン。注文を予約に関連付けます。必要に応じて、同じトークンをペイメントゲートウェイに渡すこともできます。

注文のステータスは、[新規]、[チェックアウト]、[支払い済み]、[失敗]、[発送済み]、[配信済み]、[返品済み]、[完了]のいずれかになります。ステータスShiped、Delivered、およびReturnedは、ベンダーの注文に使用できます。

注文アイテムの合計金額。

注文アイテムの合計割引。

注文アイテムに対する税金。

注文商品の送料。

注文の合計金額（税金と送料を含む）。アイテム割引は含まれません。

注文のプロモーションコード。

プロモーションコードまたはストア割引に基づく注文の合計割引。

ゲストがレストランに支払う、またはレストランがベンダーに支払う注文の総計。

ユーザーの名。

ユーザーのミドルネーム。

ユーザーの名前。

ユーザーの携帯電話番号。

ユーザーのメールアドレス。

住所を保存する最初の行。

住所を保存する2行目。

住所の都市。

住所の州。

住所の国。

注文が作成された日時が保存されます。

注文が更新された日時が保存されます。

注文の追加の詳細を保存するために使用される列。

適切な制約のある注文表は次のとおりです。

CREATE TABLE `restaurant`.`order` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NULL DEFAULT NULL,
  `vendorId` BIGINT NULL DEFAULT NULL,
  `token` VARCHAR(100) NOT NULL,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `subTotal` FLOAT NOT NULL DEFAULT 0,
  `itemDiscount` FLOAT NOT NULL DEFAULT 0,
  `tax` FLOAT NOT NULL DEFAULT 0,
  `shipping` FLOAT NOT NULL DEFAULT 0,
  `total` FLOAT NOT NULL DEFAULT 0,
  `promo` VARCHAR(50) NULL DEFAULT NULL,
  `discount` FLOAT NOT NULL DEFAULT 0,
  `grandTotal` FLOAT NOT NULL DEFAULT 0,
  `firstName` VARCHAR(50) NULL DEFAULT NULL,
  `middleName` VARCHAR(50) NULL DEFAULT NULL,
  `lastName` VARCHAR(50) NULL DEFAULT NULL,
  `mobile` VARCHAR(15) NULL,
  `email` VARCHAR(50) NULL,
  `line1` VARCHAR(50) NULL DEFAULT NULL,
  `line2` VARCHAR(50) NULL DEFAULT NULL,
  `city` VARCHAR(50) NULL DEFAULT NULL,
  `province` VARCHAR(50) NULL DEFAULT NULL,
  `country` VARCHAR(50) NULL DEFAULT NULL,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_order_user` (`userId` ASC),
  CONSTRAINT `fk_order_user`
    FOREIGN KEY (`userId`)
    REFERENCES `restaurant`.`user` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`order` 
ADD INDEX `idx_order_vendor` (`vendorId` ASC);
ALTER TABLE `restaurant`.`order` 
ADD CONSTRAINT `fk_order_vendor`
  FOREIGN KEY (`vendorId`)
  REFERENCES `restaurant`.`user` (`id`)
  ON DELETE RESTRICT
  ON UPDATE NO ACTION;

以下は、注文アイテムテーブルのすべての列の説明です。

Id アイテムID 注文ID SKU 価格割引数量単位作成場所更新日コンテンツ

注文した商品を識別するための一意のID。

注文した商品に関連付けられている商品を識別するための商品ID。

注文されたアイテムに関連付けられた注文を識別するための注文ID。

注文時のアイテムのSKU。

注文時の商品の価格。

注文時のアイテムの割引。

ユーザーが選択したアイテムの数量。

アイテムの注文時の測定単位。

注文したアイテムが作成された日時が保存されます。

注文した商品が更新された日時が保存されます。

注文した商品の詳細を保存するために使用される列。

適切な制約のある注文アイテムテーブルは次のとおりです。

CREATE TABLE `restaurant`.`order_item` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `orderId` BIGINT NOT NULL,
  `itemId` BIGINT NOT NULL,
  `sku` VARCHAR(100) NOT NULL,
  `price` FLOAT NOT NULL DEFAULT 0,
  `discount` FLOAT NOT NULL DEFAULT 0,
  `quantity` FLOAT NOT NULL DEFAULT 0,
  `unit` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_order_item_order` (`orderId` ASC),
  CONSTRAINT `fk_order_item_order`
    FOREIGN KEY (`orderId`)
    REFERENCES `restaurant`.`order` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`order_item` 
ADD INDEX `idx_order_item_item` (`itemId` ASC);
ALTER TABLE `restaurant`.`order_item` 
ADD CONSTRAINT `fk_order_item_item`
  FOREIGN KEY (`itemId`)
  REFERENCES `restaurant`.`item` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

トランザクションテーブル

また、簿記のために、ゲストがレストランに、レストランがベンダーに行った注文の支払いを追跡するためのトランザクションテーブルも必要です。同じテーブルを使用して、貸方（ゲスト）と借方（ベンダー）のトランザクションを記録することもできます。以下は、トランザクションテーブルのすべての列の説明です。

Id ユーザーID ベンダーID 注文ID コードタイプモードステータス作成場所更新日コンテンツ

トランザクションを識別するための一意のID。

トランザクションに関連付けられているユーザーを識別するためのユーザーID。

トランザクションに関連付けられているベンダーを識別するベンダーID。

トランザクションに関連付けられた注文を識別するための注文ID。

支払いゲートウェイによって提供される支払いID。

注文トランザクションのタイプは、クレジットまたはデビットのいずれかです。

注文トランザクションのモードは、オフライン、代金引換、小切手、ドラフト、有線、オンラインのいずれかです。

注文トランザクションのステータスは、新規、キャンセル、失敗、保留中、拒否、拒否、成功のいずれかになります。

注文トランザクションが作成された日時が保存されます。

注文トランザクションが更新された日時が保存されます。

トランザクションの追加の詳細を格納するために使用される列。

適切な制約のあるトランザクションテーブルは次のとおりです。

CREATE TABLE `restaurant`.`transaction` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NOT NULL,
  `vendorId` BIGINT NOT NULL,
  `orderId` BIGINT NOT NULL,
  `code` VARCHAR(100) NOT NULL,
  `type` SMALLINT(6) NOT NULL DEFAULT 0,
  `mode` SMALLINT(6) NOT NULL DEFAULT 0,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_transaction_user` (`userId` ASC),
  CONSTRAINT `fk_transaction_user`
    FOREIGN KEY (`userId`)
    REFERENCES `restaurant`.`user` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `restaurant`.`transaction` 
ADD INDEX `idx_transaction_vendor` (`vendorId` ASC),
ADD INDEX `idx_transaction_order` (`orderId` ASC);

ALTER TABLE `restaurant`.`transaction` 
ADD CONSTRAINT `fk_transaction_vendor`
  FOREIGN KEY (`vendorId`)
  REFERENCES `restaurant`.`user` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_transaction_order`
  FOREIGN KEY (`orderId`)
  REFERENCES `restaurant`.`order` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

アドレステーブル

An address table can be used to avoid the redundant columns in the Booking and Order table depending on the actual implementation. It can be directly mapped to the Booking Table and Order Table using the appropriate foreign keys.

概要

In this tutorial, we have discussed the database design of a Restaurant Ordering System or Food Ordering System to store the users, book tables, automate kitchen, and manage product inventory. The same database schema can be used to accept online table booking and pre-orders. The database schema provided in this tutorial can be considered as the starting point and further optimized or updated based on the actual needs. The On-Premises Restaurant Ordering System Flowchart can be referred to implement the restaurant order system.

コメントを送信して、ディスカッションに参加できます。 You may also be interested in designing the database of the Blog, Online Shopping Cart, and Poll &Survey applications.完全なデータベーススキーマはGitHubでも入手できます。