Dieses Tutorial enthält vollständige Schritte zum Entwerfen eines Datenbankschemas des Restaurantbestellsystems zum Verwalten der Benutzer, Tischreservierungen, Menüs, Bestände, Bestellungen und Zahlungen. Es stellt das Datenbankdesign für Essensbestellungen bereit, um die Essensbestellungen für Restaurants zu verwalten. Es kann weiter verwendet werden, um lokale Restaurant-Bestellsystemanwendungen zu entwickeln.
Solche Bestellsysteme werden implementiert, um die Bestellabwicklung zu automatisieren und Bestellspitzen effizient zu bewältigen, wodurch die Kundenzufriedenheit mit weniger Aufwand verbessert wird – eine Win-Win-Situation für Restaurantbetriebe.
Das Entity-Relationship-Diagramm oder visuelle Datenbankdesign ist unten dargestellt.
Restaurant-Bestellsystem
Notizen :Es kann für die Online-Reservierung der Tische und die Vorbestellung verwendet werden, bevor Sie das Restaurant erreichen. Die Sicherheit kann auch durch Befolgen der RBAC-Datenbank in MySQL gehandhabt werden.
Sie können auch die beliebten Tutorials besuchen, darunter How To Install MySQL 8 on Ubuntu, How To Install MySQL 8 on Windows, How To Install MySQL 8 With Workbench On Windows 10, RBAC Database in MySql, Blog Database in MySql, Quiz Database In MySQL, Datenbank für Umfragen und Umfragen in MySQL, Datenbank für Online-Einkaufswagen und Erlernen grundlegender SQL-Abfragen in MySQL.
Restaurant-Datenbank
Der allererste Schritt ist die Erstellung der Restaurant-Datenbank. Es kann mit der unten gezeigten Abfrage erstellt werden.
CREATE SCHEMA `restaurant` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Ich habe den Zeichensatz utf8mb4 verwendet um eine Vielzahl von Zeichen zu unterstützen.
Benutzertabelle
In diesem Abschnitt entwerfen wir die Benutzertabelle Benutzerinformationen zu speichern. Dieselbe Tabelle kann verwendet werden, um verschiedene Arten von Benutzern zu verwalten, darunter Administratoren, Köche, Agenten und Kunden. Es kann verwendet werden, um die Benutzer mit Menüs, Artikeln, Tischreservierungen und Bestellungen in Verbindung zu bringen. Benutzer können ihre eigenen Tische und Bestellungen verfolgen. Nachfolgend finden Sie die Beschreibung aller Spalten der Benutzertabelle.
ID | Die eindeutige ID zur Identifizierung des Benutzers. |
Vorname | Der Vorname des Benutzers. |
Zweiter Vorname | Der zweite Vorname des Benutzers. |
Nachname | Der Nachname des Benutzers. |
Mobil | Die Mobiltelefonnummer des Benutzers. Es kann für Anmelde- und Registrierungszwecke verwendet werden. |
Die E-Mail des Benutzers. Es kann für Anmelde- und Registrierungszwecke verwendet werden. | |
Passwort-Hash | Der vom entsprechenden Algorithmus generierte Passwort-Hash. Wir müssen vermeiden, einfache oder verschlüsselte Passwörter zu speichern. |
Administrator | Das Flag zur Identifizierung, ob der Benutzer ein Administrator ist. Es ist nicht erforderlich, wenn RBAC-Tabellen gemäß dem RBAC-Datenbankdesign erstellt werden. |
Anbieter | Das Flag, um zu identifizieren, ob der Benutzer Bestandsbestellungen erhalten kann. Es ist nicht erforderlich, wenn RBAC-Tabellen gemäß dem RBAC-Datenbankdesign erstellt werden. |
Koch | Das Flag zum Identifizieren, ob der Benutzer die Artikel kochen kann. Es ist nicht erforderlich, wenn RBAC-Tabellen gemäß dem RBAC-Datenbankdesign erstellt werden. |
Agent | Das Flag zur Identifizierung, ob der Benutzer eine Tabelle hosten kann. Es ist nicht erforderlich, wenn RBAC-Tabellen gemäß dem RBAC-Datenbankdesign erstellt werden. |
Registriert unter | Diese Spalte kann verwendet werden, um die Lebensdauer des Benutzers mit der Anwendung zu berechnen. |
Letzte Anmeldung | Es kann verwendet werden, um die letzte Anmeldung des Benutzers zu identifizieren. |
Einführung | Die kurze Einführung des Anbieterbenutzers, die auf der Produktseite angezeigt wird. |
Profil | Die auf der Produktseite anzuzeigenden Anbieterdetails. |
Die Benutzertabelle mit den entsprechenden Einschränkungen sieht unten aus.
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) );
Zutaten-, Artikel-, Rezept- und Menütabellen
In diesem Abschnitt entwerfen wir die Zutaten-, Artikel-, Rezept- und Menütabellen zum Speichern der Menüs und Artikeldaten.
Nachfolgend finden Sie die Beschreibung aller Spalten der Zutatentabelle . Die Zutatentabelle wird auch abgebildet, um den Lieferanten zu identifizieren, der die Zutaten liefern kann, um den Bestand aufzufüllen. In einem fortgeschritteneren Szenario kann es eine separate Tabelle zum Speichern der Beziehung zwischen Inhaltsstoff und Lieferant geben, um mehrere Lieferanten für denselben Inhaltsstoff zu unterstützen.
ID | Die eindeutige ID zur Identifizierung der Zutat. |
Benutzer-ID | Die Benutzer-ID zur Identifizierung des Administrators. |
Anbieter-ID | Die Anbieter-ID zur Identifizierung des Anbieters. |
Titel | Der Zutatentitel, der auf dem Artikelrezept angezeigt werden soll. |
Schnecke | Der eindeutige Slug, der als GID der Zutat verwendet werden soll. |
Zusammenfassung | Die Zusammenfassung, um die wichtigsten Highlights zu erwähnen. |
Typ | Der Typ, um zwischen den verschiedenen Zutatentypen zu unterscheiden. |
SKU | Die Lagerhaltungseinheit zur Verfolgung des Inhaltsstoffbestands. |
Menge | Die verfügbare Menge der Zutat. |
Einheit | Die der Zutat zugewiesene Maßeinheit. |
Erstellt am | Datum und Uhrzeit der Erstellung der Zutat werden gespeichert. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung der Zutat werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details der Zutat gespeichert werden. |
Es verwendet die Spalten Menge und Einheit, um den verfügbaren Bestand im Zutateninventar zu verfolgen. Die Zutatentabelle mit den entsprechenden Beschränkungen ist wie unten gezeigt.
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;
Nachfolgend finden Sie die Beschreibung aller Spalten der Artikeltabelle . Die Artikeltabelle wird auch abgebildet, um den Lieferanten zu identifizieren, der den nicht zum Kochen bestimmten Artikel liefern kann, um den Bestand aufzufüllen. In einem fortgeschritteneren Szenario kann es eine separate Tabelle zum Speichern des Artikels und der Lieferantenbeziehung geben, um mehrere Lieferanten für denselben Artikel zu unterstützen.
Notizen :Wir können den gleichen Tisch auch zum Speichern der Zutaten und Artikel verwenden, um die Restaurant- und Lieferantenbestellungen zu vereinfachen. In einem solchen Fall ist eine Selbstverknüpfung erforderlich, um die Artikelbestandteile zu identifizieren. Auch die Spalten Kochen und Preis sind für Zutatenzeilen nicht sinnvoll.
ID | Die eindeutige ID zur Identifizierung des Artikels. |
Benutzer-ID | Die Benutzer-ID zur Identifizierung des Administrators. |
Anbieter-ID | Die Anbieter-ID zur Identifizierung des Anbieters. |
Titel | Der im Menü anzuzeigende Elementtitel. |
Schnecke | Der eindeutige Slug, der als GID des Artikels verwendet werden soll. |
Zusammenfassung | Die Zusammenfassung, um die wichtigsten Highlights zu erwähnen. |
Typ | Der Typ, um zwischen den verschiedenen Elementtypen zu unterscheiden. |
Kochen | Das Flag, um zu identifizieren, ob für den Artikel gekocht werden muss. |
SKU | Die Stock Keeping Unit zur Verfolgung des Artikelbestands. Es ist nur erforderlich, wenn dem Artikel keine Zutaten zugeordnet sind. |
Preis | Der Verkaufspreis von entweder einer Einheit oder einer einzelnen Portion. |
Menge | Die verfügbare Menge des Artikels. Es ist nur erforderlich, wenn dem Artikel keine Zutaten zugeordnet sind. |
Einheit | Die dem Artikel zugewiesenen Maßeinheiten. Es ist nur erforderlich, wenn dem Artikel keine Zutaten zugeordnet sind. |
Rezept | Die zum Kochen des Artikels erforderlichen Anweisungen. |
Anleitung | Die Anweisungen, die zum Servieren des Artikels erforderlich sind. |
Erstellt am | Es speichert das Datum und die Uhrzeit, zu der das Element erstellt wurde. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung des Elements werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details des Artikels gespeichert werden. |
Ähnlich wie bei der Zutatentabelle werden die Spalten „Menge“ und „Einheit“ verwendet, um den verfügbaren Bestand im Artikelbestand zu verfolgen. Die Artikeltabelle mit den entsprechenden Beschränkungen ist wie unten gezeigt.
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;
Die Rezepttabelle kann verwendet werden, um die Menge der Zutaten zu verfolgen, die für einen Artikel für eine einzelne Portion benötigt werden. Unten erwähnt ist die Beschreibung aller Spalten der Rezepttabelle.
ID | Die eindeutige ID zur Identifizierung des Rezepts. |
Artikel-ID | Die Artikel-ID zur Identifizierung des Artikels. |
Zutaten-ID | Die Inhaltsstoff-ID zur Identifizierung des Inhaltsstoffs. |
Menge | Die Menge der Zutat, die benötigt wird, um das Produkt für eine einzelne Portion zuzubereiten. |
Einheit | Die Maßeinheiten zur Identifizierung der für den Artikel erforderlichen Zutatenmenge. |
Anleitung | Die zum Kochen des Artikels erforderlichen Zutatenanweisungen. |
Die Rezepttabelle mit den entsprechenden Einschränkungen ist wie unten gezeigt.
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;
Nachfolgend finden Sie die Beschreibung aller Spalten der Menütabelle . Die Menütabelle kann verwendet werden, um mehrere Menüs desselben Restaurants zu speichern.
ID | Die eindeutige ID zur Identifizierung des Menüs. |
Benutzer-ID | Die Benutzer-ID zur Identifizierung des Administrators. |
Titel | Der auf der Menükarte anzuzeigende Menütitel. |
Schnecke | Der eindeutige Slug, der als GID des Menüs verwendet werden soll. |
Zusammenfassung | Die Zusammenfassung, um die wichtigsten Highlights der Menükarte zu erwähnen. |
Typ | Der Typ, um zwischen den verschiedenen Menütypen zu unterscheiden. |
Erstellt am | Es speichert das Datum und die Uhrzeit, zu der das Element erstellt wurde. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung des Elements werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details des Menüs gespeichert werden. |
Die Menütabelle mit den entsprechenden Beschränkungen ist wie unten gezeigt.
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);
Die Menüpunkttabelle kann verwendet werden, um die auf der Menükarte verfügbaren Elemente zu verfolgen. Unten erwähnt ist die Beschreibung aller Spalten der Menüeintragstabelle.
ID | Die eindeutige ID zur Identifizierung des Menüpunkts. |
Menü-ID | Die Menü-ID zur Identifizierung des Menüs. |
Artikel-ID | Die Artikel-ID zur Identifizierung des Artikels. |
Aktiv | Das Flag, um zu prüfen, ob der Artikel verfügbar ist. |
Die Menüeintragstabelle mit den entsprechenden Beschränkungen ist wie unten gezeigt.
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;
Der Item Chef Table kann verwendet werden, um den Küchenchef zu identifizieren, der das Gericht zubereiten soll. Nachfolgend finden Sie die Beschreibung aller Spalten der Item Chef-Tabelle.
ID | Die eindeutige ID zur Identifizierung des Menüpunkts. |
Artikel-ID | Die Artikel-ID zur Identifizierung des Artikels. |
Chef-ID | Die Koch-ID zur Identifizierung des Benutzers. |
Aktiv | Das Flag, um zu prüfen, ob der Koch verfügbar ist, um das Gericht zuzubereiten. |
Die Tabelle „Item Chef“ mit den entsprechenden Beschränkungen ist unten dargestellt.
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;
TableTop und Buchungstische
In diesem Abschnitt entwerfen wir die TableTop- und Buchungstische um die Restauranttische und ihre Buchungsdetails zu speichern.
Der TableTop-Tisch kann verwendet werden, um die Details der Tische im Restaurant zu speichern. Der Status der Tabelle kann Frei, Reserviert und Aktiv sein. Ich habe TableTop anstelle von Table verwendet, um es vom Schlüsselwort table von MySQL zu unterscheiden. Unten erwähnt ist die Beschreibung aller Spalten der TableTop-Tabelle.
ID | Die eindeutige ID zur Identifizierung der Tabelle. |
Code | Der Tabellencode. |
Status | Die Rezensionsbewertung. |
Kapazität | Die Gesamtsitzkapazität des Tisches. |
Erstellt am | Es speichert das Datum und die Uhrzeit, zu der die Tabelle erstellt wurde. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung der Tabelle werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details der Tabelle gespeichert werden. |
Die TableTop-Tabelle mit den entsprechenden Einschränkungen sieht unten aus.
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`));
Buchungstabelle kann verwendet werden, um die Restauranttische entweder online oder vor Ort zu buchen. Ein angemeldeter oder bestehender Benutzer kann auch mit Booking verknüpft werden. Es wird auch davon ausgegangen, dass nur die Tische mit dem Status Frei reserviert werden können. Der Tischstatus kann nach Bestätigung der Buchung auf Reserviert geändert werden. Außerdem kann der Tischstatus auf Aktiv gesetzt werden, sobald die Gäste ihn belegen. Unten erwähnt ist die Beschreibung aller Spalten der Buchungstabelle.
Notizen :Die Buchungstabelle deckt nicht die Zahlungen ab, die mit der Buchung des Tisches verbunden sind. Es kann weiter aktualisiert werden, indem zusätzliche Spalten hinzugefügt werden, um die Zahlungen zu handhaben, die mit der Buchung des Tisches verbunden sind.
ID | Die eindeutige ID zur Identifizierung der Buchung. |
Tabellen-ID | Die Tisch-ID zur Identifizierung des mit der Buchung verbundenen Tisches. |
Benutzer-ID | Die Benutzer-ID zur Identifizierung des registrierten Benutzers, der mit der Buchung verbunden ist. |
Token | Das der Buchung zugeordnete eindeutige Token. |
Status | Der Status der Buchung kann Neu, Lounge, Aktiv und Abgeschlossen sein. |
Vorname | Der Vorname des Gastes. |
Zweiter Vorname | Der zweite Vorname des Gastes. |
Nachname | Der Nachname des Benutzers. |
Mobil | Die Handynummer des Benutzers. |
Die E-Mail des Benutzers. | |
Zeile 1 | Die erste Zeile zum Speichern der Adresse. |
Zeile 2 | Die zweite Zeile zum Speichern der Adresse. |
Stadt | Die Stadt der Adresse. |
Provinz | Die Provinz der Adresse. |
Land | Das Land der Adresse. |
Erstellt am | Es speichert das Datum und die Uhrzeit, zu der die Buchung erstellt wurde. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung der Buchung werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details der Buchung gespeichert werden. |
Die Buchungstabelle mit den entsprechenden Einschränkungen ist unten dargestellt.
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;
Die Buchungsartikeltabelle ist erforderlich, um die vom Gast bestellten Artikel zu verfolgen. Nachfolgend finden Sie die Beschreibung aller Spalten der Buchungspostentabelle.
ID | Die eindeutige ID zur Identifizierung des Buchungsartikels. |
Buchungs-ID | Die Buchungs-ID zur Identifizierung der mit dem Buchungsartikel verknüpften Buchung. |
Artikel-ID | Die Artikel-ID zur Identifizierung des mit dem Buchungsartikel verknüpften Artikels. |
SKU | Die SKU des Artikels während der Bestellung. |
Preis | Der Verkaufspreis des Artikels während der Bestellung. |
Rabatt | Der Rabatt des Artikels bei der Bestellung. |
Menge | Die Menge des vom Benutzer bestellten Artikels. Es kann entweder der Multiplikator der Artikeleinheit oder der Einzelportion sein. |
Einheit | Die Maßeinheiten bei der Bestellung des Artikels. |
Status | Der Status zum Verfolgen des Artikelfortschritts. Es kann Neu, Küche, Kochen, Gekocht, Serviert sein. |
Erstellt am | Es speichert das Datum und die Uhrzeit, zu der die Buchungsposition erstellt wurde. |
Aktualisiert um | Es speichert das Datum und die Uhrzeit, zu der die Buchungsposition aktualisiert wird. |
Inhalt | Die Spalte, in der die zusätzlichen Details des Buchungsartikels gespeichert werden. |
Die Buchungspostentabelle mit den entsprechenden Einschränkungen ist unten dargestellt.
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;
Bestelltabelle und Bestellartikeltabelle
Dieser Abschnitt enthält die Tabellen zur Verwaltung der Bestellungen. Der Bestellung kann auch ein eingeloggter Benutzer zugeordnet werden. Die Bestelltabelle kann verwendet werden, um die abgeschlossenen Buchungen und Lieferantenbestellungen zu speichern. Der Lieferantenbestellungsstatus kann auf Neu gesetzt werden, während die Bestellung aufgegeben wird, und er kann auf Abgeschlossen gesetzt werden, nachdem die Artikel vom Lieferanten erhalten wurden. Außerdem muss der Artikelpreis manuell ausgefüllt werden, nachdem die Artikel vom Lieferanten erhalten wurden. Unten erwähnt ist die Beschreibung aller Spalten der Auftragstabelle.
ID | Die eindeutige ID zur Identifizierung der Bestellung. |
Benutzer-ID | Die Benutzer-ID zur Identifizierung des mit der Bestellung verbundenen Gastes. |
Anbieter-ID | Die Anbieter-ID zur Identifizierung des mit der Bestellung verknüpften Anbieters. |
Token | Der eindeutige Token, der der Bestellung zugeordnet ist, um sie mit der Buchung zu verknüpfen. Derselbe Token kann bei Bedarf auch an das Payment Gateway übergeben werden. |
Status | Der Status der Bestellung kann Neu, Zur Kasse, Bezahlt, Fehlgeschlagen, Versendet, Geliefert, Retourniert und Abgeschlossen sein. Für Lieferantenbestellungen können die Status Versendet, Geliefert und Retourniert verwendet werden. |
Zwischensumme | Der Gesamtpreis der Bestellartikel. |
Artikelrabatt | Der Gesamtrabatt der Bestellartikel. |
Steuer | Die Steuer auf die Bestellartikel. |
Versand | Die Versandkosten der Bestellartikel. |
Gesamt | Der Gesamtpreis der Bestellung einschließlich Steuern und Versand. Es schließt den Artikelrabatt aus. |
Promo | Der Promo-Code der Bestellung. |
Rabatt | Der Gesamtrabatt der Bestellung basierend auf dem Promo-Code oder Shop-Rabatt. |
Gesamtsumme | Die Gesamtsumme der Bestellung, die vom Gast an das Restaurant oder vom Restaurant an den Verkäufer zu zahlen ist. |
Vorname | Der Vorname des Benutzers. |
Zweiter Vorname | Der zweite Vorname des Benutzers. |
Nachname | Der Nachname des Benutzers. |
Mobil | Die Handynummer des Benutzers. |
Die E-Mail des Benutzers. | |
Zeile 1 | Die erste Zeile zum Speichern der Adresse. |
Zeile 2 | Die zweite Zeile zum Speichern der Adresse. |
Stadt | Die Stadt der Adresse. |
Provinz | Die Provinz der Adresse. |
Land | Das Land der Adresse. |
Erstellt am | Datum und Uhrzeit der Auftragserstellung werden gespeichert. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung der Bestellung werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details der Bestellung gespeichert werden. |
Die Bestelltabelle mit den entsprechenden Einschränkungen ist unten dargestellt.
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;
Nachfolgend finden Sie die Beschreibung aller Spalten der Bestellartikeltabelle.
ID | Die eindeutige ID zur Identifizierung des bestellten Artikels. |
Artikel-ID | Die Produkt-ID zur Identifizierung des mit dem bestellten Artikel verknüpften Artikels. |
Bestell-ID | Die Bestell-ID zur Identifizierung der mit dem bestellten Artikel verknüpften Bestellung. |
SKU | Die SKU des Artikels während der Bestellung. |
Preis | Der Preis des Artikels während der Bestellung. |
Rabatt | Der Rabatt des Artikels bei der Bestellung. |
Menge | Die Menge des vom Benutzer ausgewählten Artikels. |
Einheit | Die Maßeinheiten bei der Bestellung des Artikels. |
Erstellt am | Es speichert Datum und Uhrzeit der Erstellung des bestellten Artikels. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung des bestellten Artikels werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details des bestellten Artikels gespeichert werden. |
Die Bestellpostentabelle mit den entsprechenden Einschränkungen ist unten dargestellt.
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;
Transaktionstabelle
Wir brauchen auch eine Transaktionstabelle, um die Bestellzahlungen der Gäste an das Restaurant und das Restaurant an die Verkäufer für die Buchhaltung zu verfolgen. Wir können dieselbe Tabelle auch verwenden, um die Guthaben- (Gäste) und Soll- (Verkäufer) Transaktionen aufzuzeichnen. Unten erwähnt ist die Beschreibung aller Spalten der Transaktionstabelle.
ID | Die eindeutige ID zur Identifizierung der Transaktion. |
Benutzer-ID | Die Benutzer-ID zur Identifizierung des mit der Transaktion verknüpften Benutzers. |
Anbieter-ID | Die Anbieter-ID zur Identifizierung des mit der Transaktion verknüpften Anbieters. |
Bestell-ID | Die Bestell-ID zur Identifizierung der mit der Transaktion verknüpften Bestellung. |
Code | Die vom Zahlungsgateway bereitgestellte Zahlungs-ID. |
Typ | Die Art der Bestelltransaktion kann entweder Gutschrift oder Lastschrift sein. |
Modus | Der Modus der Bestelltransaktion kann Offline, Nachnahme, Scheck, Wechsel, Kabelgebunden und Online sein. |
Status | Der Status der Bestelltransaktion kann Neu, Storniert, Fehlgeschlagen, Ausstehend, Abgelehnt, Abgelehnt und Erfolg sein. |
Erstellt am | Datum und Uhrzeit der Erstellung des Bestellvorgangs werden gespeichert. |
Aktualisiert um | Datum und Uhrzeit der Aktualisierung der Bestelltransaktion werden gespeichert. |
Inhalt | Die Spalte, in der die zusätzlichen Details der Transaktion gespeichert werden. |
Die Transaktionstabelle mit den entsprechenden Beschränkungen ist wie unten gezeigt.
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;
Address Table
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.
Zusammenfassung
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.
Sie können Ihre Kommentare einreichen, um an der Diskussion teilzunehmen. You may also be interested in designing the database of the Blog, Online Shopping Cart, and Poll &Survey applications. Das vollständige Datenbankschema ist auch auf GitHub verfügbar.