Hungrig, aber keine Lust zu kochen? Rufen Sie ein Restaurant an, bestellen Sie Ihr Lieblingsessen und informieren Sie sich über ein Datenmodell, das den gesamten Prozess organisieren kann.
Trotz einer Fülle von „zeitsparender“ Technologie scheint uns weniger Zeit zu bleiben, um Grundbedürfnisse – wie Essen – zu erfüllen. Wenn wir etwas essen möchten, aber nicht die Zeit (oder die Fähigkeiten) haben, es selbst zu kochen, können wir Essen von einem Restaurant bestellen (d. h. einem Imbiss oder Imbiss), das unsere Mahlzeiten direkt zu unserer Tür bringt. Natürlich müssen wir für diesen Komfort bezahlen, also erwarten wir, dass das Essen gut und heiß ist!
Offensichtlich ist jedes Restaurant motiviert, seine Kunden zufrieden zu stellen. Sie werden überrascht sein zu erfahren, wie viel Arbeit in den Betrieb eines Imbisses gesteckt wird. Die meisten verwenden eine Art Tracking-System, um Bestellungen und Lieferungen zu verwalten. Schauen wir uns das Datenmodell unter einem solchen System an. Holen Sie sich einen Snack, lehnen Sie sich zurück und genießen Sie den Artikel.
Was sollten wir über das Restaurantgeschäft wissen?
Lebensmittel zuzubereiten und an Kunden zu liefern, ist nicht einfach. Zuallererst müssen Sie Talent und Wissen haben, um köstliche Mahlzeiten zuzubereiten. Auch Sie müssen organisiert sein:Damit diese Mahlzeiten pünktlich und an den richtigen Ort geliefert werden, muss alles perfekt funktionieren!
Bevor wir mit der Lieferung von Mahlzeiten beginnen, müssen wir Folgendes wissen:
- Wer hat das Essen bestellt?
- Wo und wann das Essen geliefert werden soll
- Welche Gerichte sind in der Bestellung enthalten
- Welche Zutaten wir zur Erfüllung der Bestellung benötigen
- Wenn die Bestellung bereits bezahlt wurde
Wir müssen auch den Lieferstatus verfolgen und Kundenfeedback über ihre Mahlzeit und/oder unseren Lieferprozess aufzeichnen. Außerdem möchten wir vielleicht wissen, welche Mahlzeiten am beliebtesten (oder am wenigsten) beliebt sind. Und wir sollten auch einige Finanzinformationen für Berichts- und Analysezwecke aufbewahren.
Nehmen wir an, wir haben eine App, mit der unsere Kunden Bestellungen für die Lieferung aufgeben können. Es ermöglicht ihnen, Menüpunkte auszuwählen, zu bezahlen und eine Lieferzeit und Adresse anzugeben. Wie könnte das Datenmodell einer solchen App aussehen?
Das Datenmodell
Sie können dieses Modell in Ihrem Browser öffnen, indem Sie auf Edit model in your browser klicken Taste.
Das Datenmodell besteht aus drei Themenbereichen:
Restaurants & customersMenusOrders
Wir präsentieren jeden Themenbereich in der Reihenfolge, in der er aufgeführt ist.
Restaurants und Kunden
Die Restaurants & customers Themenbereich enthält drei Tabellen, die Details über unsere Restaurants (es kann mehr als eines geben), die Städte, in denen wir tätig sind, und unsere Kunden speichern.
Sowohl Kunden als auch Restaurants befinden sich in Städten (oder Städten, Dörfern usw.). Daher brauchen wir eine city Wörterbuch. Es enthält nur zwei Attribute, city_name und zip_code . Wenn wir in mehr als einem Land tätig sind, benötigen wir auch ein Länderwörterbuch, das sich auf diese Tabelle bezieht, aber darauf gehen wir hier nicht ein.
Als nächstes benötigen wir eine Liste aller Restaurants, die wir betreiben. Wir verwenden das restaurant Tisch dazu. Der Einfachheit halber speichern wir nur die address jedes Restaurants und einen Verweis auf die city wo es sich befindet.
Die letzte Tabelle in diesem Themenbereich ist der customer Tisch. Hier speichern wir eine Liste aller unserer registrierten Lieferkunden. Wir verwenden Daten aus dieser Tabelle, um Kunden später im Modell mit ihren Bestellungen zu verknüpfen. Natürlich müssen Kunden nicht in unserem Modell registriert sein, um eine Bestellung aufzugeben, aber wir brauchen diese Liste trotzdem. Als Treueprogramm könnten wir registrierten Kunden Rabatte anbieten. Oder vielleicht würden wir diese Daten verwenden, um Kunden mit Sonderangeboten zu kontaktieren. Für jeden registrierten Kunden speichern wir:
customer_name– Der vollständige Name des Kunden.city_id– Verweist aufcitywo der Kunde wohnt.address– Die Adresse des Kunden.contact_phone– Die Telefonnummer des Kunden.email– Die E-Mail-Adresse, die der Kunde während des Registrierungsprozesses verwendet hat.confirmation_code– Ein Bestätigungscode, der während des Registrierungsprozesses verwendet wird.password– Das vom Kunden gewählte Passwort für diese App.time_joined– Ein Zeitstempel, wann der Kunde unserer Anwendung beigetreten ist.
Menüs
In diesem Themenbereich finden Sie Informationen zu den Speisekarten unserer Restaurants. Nehmen wir zunächst an, dass alle unsere Restaurants dieselbe Speisekarte verwenden.
Die erste Tabelle ist die category Wörterbuch. Es enthält nur ein UNIQUE-Attribut, category_name . Dieses Feld enthält wahrscheinlich die üblichen Menükategorien wie „Getränke“, „Vorspeisen“, „Salate“, „Sandwiches“, „Pizza“ usw.
Als nächstes haben wir das menu_item Tisch. Es listet alle Artikel auf, die wir auf unseren Speisekarten haben (oder hatten). Für jeden Artikel speichern wir:
item_name– Ein Name für dieses Element, z. „Hähnchen-Sandwich“.category_id– Verweist auf diecategorydem der Gegenstand gehört, z. „Sandwiches“.description– Eine Beschreibung dieses Artikels. Dies sollte dasselbe sein wie auf der gedruckten Speisekarte.ingredients– Die zur Herstellung dieses Artikels verwendeten Zutaten und deren Mengen. Dieses Feld könnte tatsächlich ein Rezept speichern.price– Der aktuelle Preis für einen Artikel (z. B. ein Hühnchen-Sandwich).active– Wenn der Artikel im aktuellen Menü angeboten wird.
Wenn wir Menüs in mehreren Sprachen speichern möchten, sollten wir einen Ansatz wie den in diesem Artikel vorgestellten verwenden.
Die meisten Restaurants haben spezielle, zeitlich begrenzte Angebote. Sie können auch einige Angebote für eine unbegrenzte Zeit haben. Wir nutzen das offer Tabelle für diese. Für jeden haben wir:
date_active_fromunddate_active_to– Zusammen definieren diese, wann dieses Angebot aktiv ist. Wenn ein Angebot eine unbegrenzte Dauer hat oder auf Stunden statt auf Tagen basiert, enthalten diese beiden Attribute NULL-Werte. Ein Beispiel für diese Art von Angebot ist „Kaufen Sie im März ein Curry und erhalten Sie 50 % Rabatt auf eins.“time_active_fromundtime_active_to– Definiert die Tageszeit, zu der ein Angebot gültig ist – z. „Bekomme jeden Tag von 6-9 Uhr einen kostenlosen Kaffee.“offer_price– Der Preis für dieses Angebot.
Alle in Angeboten enthaltenen Menüpunkte werden im in_offer Tisch. Diese Tabelle enthält das EINZIGARTIGE Paar offer_id – menu_item_id .
Wenn unsere Restaurants unterschiedliche Speisekarten haben, müssen wir für jedes Restaurant eine separate Speisekarte erstellen. Wir müssten dann Menüs und Angebote mit Restaurants mit Fremdschlüsseln in Beziehung setzen. Dies würde es uns ermöglichen, Menüs und Angebote für jedes Restaurant zu ändern, ohne die anderen zu beeinträchtigen. Dies würde nicht nur die Datenbank verkomplizieren; auch das Geschäftsmodell würde komplexer werden. Aus diesem Grund bleiben die meisten Restaurantketten bei nur einem Menü und ich habe mich entschieden, diese Methode in diesem Modell nicht zu verwenden.
Bestellungen
Der letzte Themenbereich in unserem Modell sind die Orders Fachbereich. Hier haben wir alles, was zum Speichern von Bestellungen und deren Status benötigt wird.
Die zentrale Tabelle hier ist placed_order Tisch. Am besten verwenden Sie nicht nur „order“ als Namen für diese Tabelle:„order“ ist ein SQL-Schlüsselwort. Versuchen Sie, keine Schlüsselwörter als Namen für Tabellen und Spalten zu verwenden; Andernfalls können beim Schreiben von Abfragen Fehler auftreten. Für jede Bestellung erfassen wir:
restaurant_id– Die ID desrestaurantim Zusammenhang mit dieser Bestellung.order_time– Ein Zeitstempel, wann die Bestellung aufgegeben wurde.estimated_delivery_time– Ein Zeitstempel der geplanten Lieferung dieser Bestellung.food_ready– Ein Zeitstempel, der angibt, wann die Bestellpositionen vorbereitet wurden. Dieser enthält einen NULL-Wert, bis das Essen zubereitet ist. Wir könnten dieses Attribut verwenden, um die Zeitdifferenz zwischen dem Moment der Bestellung und der Zubereitung des Essens zu berechnen. Wir könnten es auch verwenden, um herauszufinden, wie viel Zeit zwischen der Fertigstellung und der Lieferung des Essens verstrichen ist. Diese Informationen können sehr hilfreich sein, um die Effizienz der Mitarbeiter zu steigern.actual_delivery_time– Ein Zeitstempel, wann diese Bestellung tatsächlich geliefert wurde. Es ist NULL, bis das Essen an den Kunden geliefert wird.delivery_address– Die Adresse, an die die Bestellung geliefert werden soll.customer_id– Die ID descustomerwer diese Bestellung aufgegeben hat. Dieses Attribut könnte einen NULL-Wert enthalten, wenn die Bestellung von jemandem aufgegeben wurde, der kein registrierter App-Benutzer ist.price– Der Preis für alle Artikel, die in dieser Bestellung enthalten sind.discount– Die Höhe des Rabatts (z. B. Gutschein- oder Treuerabatt), der gegebenenfalls auf den Preis angewendet wird.final_price– Der Bestellpreis abzüglich des Rabatts.comment– Zusätzliche Kommentare, die vom Kunden bei der Bestellung eingefügt wurden. Dies können zusätzliche Lieferanweisungen oder alles andere sein, was der Kunde wichtig findet.ts– Ein Zeitstempel, wann dieser Datensatz in die Tabelle eingefügt wurde.
Der in_order Tabelle listet alle Artikel oder Sonderangebote auf, die in einer Bestellung enthalten sind. Für jeden Datensatz in dieser Tabelle speichern wir:
placed_order_id– Die ID der zugehörigenorder.offer_id– Verweist auf dasofferTabelle, aber nur wenn ein oder mehrere Angebote in dieser Bestellung enthalten sind. In diesem Fall diemenu_item_idAttribut ist NULL.menu_item_id– Verweist aufmenu_itemTabelle, aber nur, wenn sich dieser Datensatz auf einen Menüpunkt und nicht auf ein Angebot bezieht.quantity– Wie viele Angebote oder Menüpunkte sind in dieser Bestellung enthalten.item_price– Der Preis für ein einzelnes Angebot oder einen Menüpunkt.price– Der Gesamtpreis für diese Position, ausgedrückt alsitem_price*quantity.comment– Vom Kunden eingefügte Kommentare, die sich speziell auf diese Bestellposition beziehen, z. „Pizza bitte in 8 Scheiben schneiden“.
Der comment Tabelle können wir das Einfügen mehrerer Kommentare zu Bestellungen unterstützen. Für jeden Kommentar speichern wir die ID der zugehörigen Bestellung und die ID des Kunden. Wir speichern auch einen Zeitstempel, wann dieser Kommentar eingegeben wurde. Wir markieren auch, ob dieser Kommentar eine Beschwerde oder ein Kompliment war; nur einer dieser beiden kann gleichzeitig eingestellt werden. Wenn keine festgelegt sind, behandeln wir diesen Kommentar als neutral.
Die letzten beiden Tabellen in unserem Modell beziehen sich auf Status, die wir Bestellungen zuweisen. Der status_catalog Tabelle enthält eine Liste aller möglichen UNIQUE status_name Attribute, die wir Aufträgen zuweisen könnten. Der order_status Tabelle enthält alle Status, die Aufträgen zugeordnet sind. Für jeden Datensatz in dieser Tabelle speichern wir Fremdschlüssel in Bezug auf Bestellung und Status sowie den Zeitstempel, als dieser Status zugewiesen wurde.
Was denken Sie über das Lieferdatenmodell für Restaurants?
Heute haben wir ein Datenmodell besprochen, das zum Organisieren, Verwalten und Speichern von Lieferaufträgen für Restaurants verwendet werden könnte. Wir können den Status jeder Bestellung und einige der finanziellen Details verfolgen. Ich habe ein paar Ideen, wie wir dieses Modell robuster machen könnten, aber ich würde gerne Ihre Meinung hören. Bitte teilen Sie es im Kommentarbereich!
