En restaurantleveringsdatamodel

Sulten, men vil du ikke lave mad? Ring til en restaurant, bestil dit yndlingsmåltid, og læs om en datamodel, der kan organisere hele processen.

På trods af en overflod af "tidsbesparende" teknologi, ser det ud til, at vi har mindre tid til at opfylde basale behov - såsom at spise. Hvis vi vil spise noget, men vi ikke har tiden (eller evnerne) til at lave det selv, kan vi bestille mad fra en restaurant (dvs. en takeaway eller takeaway), som bringer vores måltider lige til døren. Vi skal selvfølgelig betale for denne bekvemmelighed, så vi forventer, at maden er god og varm!

Det er klart, at enhver restaurant er motiveret for at holde sine kunder tilfredse. Du kan blive overrasket over at høre, hvor meget arbejde der ligger i at køre en takeaway. De fleste bruger en eller anden form for sporingssystem til at administrere ordrer og leverancer. Lad os se på datamodellen under et sådant system. Snup dig selv en snack, læn dig tilbage, og nyd artiklen.

Hvad bør vi vide om restaurationsbranchen?

Det er ikke nemt at lave mad og levere det til kunderne. Først og fremmest skal du have talent og viden for at tilberede lækre måltider. Du skal også være organiseret:alt skal fungere perfekt, hvis disse måltider skal leveres til tiden og til det rigtige sted!

Før vi begynder at levere måltider, skal vi vide:

Hvem bestilte måltidet
Hvor og hvornår måltidet skal leveres
Hvilke retter er inkluderet i bestillingen
Hvilke ingredienser skal vi bruge for at opfylde ordren
Hvis ordren allerede er betalt

Vi skal også spore leveringsstatusser og registrere kundefeedback om deres måltid og/eller vores leveringsproces. Derudover vil vi måske gerne vide, hvilke måltider der er mest (eller mindst) populære. Og vi bør også opbevare nogle finansielle oplysninger til rapportering og analyseformål.

Lad os antage, at vi har en app, som vores kunder kan bruge til at afgive ordrer til levering. Det giver dem mulighed for at vælge menupunkter, betale for dem og angive leveringstid og adresse. Hvordan kan datamodellen under sådan en app se ud?

Datamodellen

Du kan åbne denne model i din browser ved at klikke på Edit model in your browser knap.

Datamodellen består af tre emneområder:

Restaurants & customers
Menus
Orders

Vi præsenterer hvert emneområde i den rækkefølge, det er angivet.

Restauranter og kunder

Restaurants & customers emneområdet indeholder tre tabeller, der gemmer detaljer om vores restauranter (der kan være mere end én), de byer, hvor vi opererer, og vores kunder.

Både kunder og restauranter er placeret i byer (eller byer, landsbyer osv.). Derfor har vi brug for en city ordbog. Den indeholder kun to attributter, city_name og zip_code . Hvis vi opererer i mere end ét land, ville vi også have brug for en landeordbog, der ville være relateret til denne tabel, men det vil vi ikke gå ind på her.

Dernæst har vi brug for en liste over alle de restauranter, vi driver. Vi bruger restaurant bord til det. For at gøre tingene simple gemmer vi kun hver restaurants address og en henvisning til city hvor den er placeret.

Den sidste tabel i dette emneområde er customer bord. Det er her, vi gemmer en liste over alle vores registrerede leveringskunder. Vi bruger data fra denne tabel til at linke kunder til deres ordrer senere i modellen. Kunder skal selvfølgelig ikke være registreret i vores model for at afgive en ordre, men vi har stadig brug for denne liste. Vi kunne tilbyde rabatter til registrerede kunder som et loyalitetsprogram. Eller måske ville vi bruge disse data til at kontakte kunder med særlige tilbud. For hver registreret kunde gemmer vi:

customer_name – Kundens fulde navn.
city_id – Henviser til city hvor kunden bor.
address – Kundens adresse.
contact_phone – Kundens telefonnummer.
email – Den e-mailadresse, som kunden brugte under registreringsprocessen.
confirmation_code – En bekræftelseskode, der bruges under registreringsprocessen.
password – Adgangskoden valgt af kunden til denne app.
time_joined – Et tidsstempel for, hvornår kunden tiltrådte vores applikation.

Menuer

Dette emneområde indeholder information om vores restauranters menuer. Lad os nu antage, at alle vores restauranter bruger den samme menu.

Den første tabel er category ordbog. Den indeholder kun én UNIK attribut, category_name . Dette felt vil sandsynligvis indeholde de sædvanlige menukategorier, såsom "drikkevarer", "forretter", "salater", "sandwich", "pizza" osv.

Dernæst har vi menu_item bord. Den viser alle varer, vi har (eller havde) på en af vores menuer. For hver vare gemmer vi:

item_name – Et navn for den vare, f.eks. "kyllingesandwich".
category_id – Refererer til category at varen tilhører, f.eks. "sandwich".
description – En beskrivelse af den pågældende vare. Dette bør være det samme som på den udskrevne menu.
ingredients – De ingredienser, der er brugt til at fremstille den pågældende vare og deres mængder. Dette felt kunne faktisk gemme en opskrift.
price – Den aktuelle pris for én vare (f.eks. én kyllingesandwich).
active – Hvis punktet tilbydes i den aktuelle menu.

Hvis vi ønsker at gemme menuer på flere sprog, bør vi bruge en tilgang som den, der præsenteres i denne artikel.

De fleste restauranter har særlige, tidsbegrænsede tilbud. De kan også have nogle tilbud i et ubegrænset tidsrum. Vi bruger offer bord til disse. For hver enkelt har vi:

date_active_from og date_active_to – Tilsammen definerer disse, hvornår dette tilbud er aktivt. Hvis et tilbud har en ubegrænset varighed, eller hvis det er baseret på timer i stedet for dage, vil disse to attributter indeholde NULL-værdier. Et eksempel på denne type tilbud er "I løbet af marts måned, køb en karry og få en 50% rabat".
time_active_from og time_active_to – Definerer tidspunktet på dagen et tilbud er gyldigt – f.eks. "Få en gratis kaffe fra kl. 6-9 hver dag".
offer_price – Prisen for det tilbud.

Alle menupunkter inkluderet i tilbud gemmes i in_offer bord. Denne tabel indeholder det UNIKKE par offer_id – menu_item_id .

Hvis vores restauranter har forskellige menuer, skal vi lave en separat menu for hver restaurant. Vi bliver så nødt til at relatere menuer og tilbud til restauranter ved hjælp af fremmednøgler. Dette ville give os mulighed for at ændre menuer og tilbud for enhver restaurant uden at påvirke de andre. Dette ville ikke bare komplicere databasen; forretningsmodellen ville også blive mere kompleks. Det er grunden til, at de fleste restaurantkæder kun holder fast i én menu, og derfor besluttede jeg ikke at bruge denne metode i denne model.

Ordrer

Det sidste emneområde i vores model er Orders emneområde. Det er her, vi har alt det nødvendige for at gemme ordrer og deres status.

Den centrale tabel her er placed_order bord. Det er bedst ikke kun at bruge "ordre" som navnet på denne tabel:"ordre" er et SQL-nøgleord. Prøv at undgå at bruge nøgleord som navne på tabeller og kolonner; ellers kan du få fejl, når du skriver forespørgsler. For hver ordre registrerer vi:

restaurant_id – ID'et for restaurant relateret til den ordre.
order_time – Et tidsstempel for, hvornår ordren blev afgivet.
estimated_delivery_time – Et tidsstempel for den planlagte levering af denne ordre.
food_ready – Et tidsstempel, der angiver, hvornår ordrevarerne blev forberedt. Dette vil indeholde en NULL-værdi, indtil maden er tilberedt. Vi kunne bruge denne egenskab til at beregne tidsforskellen mellem det øjeblik, ordren blev afgivet, og hvornår maden blev tilberedt. Vi kunne også bruge den til at finde ud af, hvor lang tid der gik mellem maden var klar til den blev leveret. Disse oplysninger kan være meget nyttige i forhold til at øge personalets effektivitet.
actual_delivery_time – Et tidsstempel for, hvornår denne ordre rent faktisk blev leveret. Den vil være NULL indtil maden er leveret til kunden.
delivery_address – Adressen, hvor ordren skal leveres.
customer_id – ID'et for customer hvem afgav den ordre. Denne attribut kan indeholde en NULL-værdi, hvis ordren blev afgivet af en person, der ikke er en registreret appbruger.
price – Prisen for alle varer inkluderet i den pågældende ordre.
discount – Rabatbeløbet (f.eks. kupon eller loyalitetsrabat) anvendt på prisen, hvis nogen.
final_price – Ordreprisen minus rabatten.
comment – Yderligere kommentarer indsat af kunden, da ordren blev afgivet. Dette kan være yderligere leveringsinstruktioner eller andet, som kunden finder vigtigt.
ts – Et tidsstempel for, hvornår denne post blev indsat i tabellen.

in_order tabel viser alle varer eller specialtilbud, der er inkluderet i en ordre. For hver post i denne tabel gemmer vi:

placed_order_id – ID'et for den relaterede order .
offer_id – Henviser til offer tabel, men kun når et eller flere tilbud indgår i denne ordre. I så fald er menu_item_id attribut vil være NULL.
menu_item_id – Henviser til menu_item tabel, men kun hvis denne post er relateret til et menupunkt og ikke et tilbud.
quantity – Hvor mange tilbud eller menupunkter er inkluderet i denne ordre.
item_price – Prisen for et enkelt tilbud eller menupunkt.
price – Den samlede pris for denne linje, udtrykt som item_price * quantity .
comment – Eventuelle kommentarer indsat af kunden, der specifikt vedrører den pågældende ordrevare, f.eks. "Skær pizza i 8 skiver".

comment tabel lader os understøtte indsættelsen af flere kommentarer relateret til ordrer. For hver kommentar gemmer vi ID'et for den relaterede ordre og kundens ID. Vi gemmer også et tidsstempel for, hvornår denne kommentar blev indtastet. Vi markerer også, om denne kommentar var en klage eller en kompliment; kun én af disse to kan indstilles på én gang. Hvis ingen er indstillet, behandler vi denne kommentar som neutral.

De sidste to tabeller i vores model er relateret til statusser, vi tildeler ordrer. status_catalog tabel indeholder en liste over alle mulige UNIQUE status_name egenskaber, som vi kunne tildele ordrer. order_status tabel indeholder alle statusser, der er tildelt ordrer. For hver post i denne tabel gemmer vi fremmednøgler relateret til ordre og status og tidsstemplet, da denne status blev tildelt.

Hvad synes du om restaurantleveringsdatamodellen?

I dag har vi diskuteret en datamodel, der kunne bruges til at organisere, administrere og opbevare restaurantleveringsordrer. Vi kan spore status for hver ordre og nogle af de økonomiske detaljer. Jeg har et par ideer til, hvordan vi kan gøre denne model mere robust, men jeg ville være glad for at høre din mening. Del det venligst i kommentarfeltet!