En datamodell för restaurangleverans

Hungrig men vill du inte laga mat? Ring en restaurang, beställ din favoritmåltid och läs om en datamodell som kan organisera hela processen.

Trots ett överflöd av "tidsbesparande" teknologi verkar vi ha mindre tid på oss att uppfylla grundläggande behov – som att äta. Om vi vill äta något men vi inte har tid (eller färdigheter) att laga det själva, kan vi beställa mat från en restaurang (dvs en takeaway eller takeaway), som tar våra måltider direkt till våra dörrar. Naturligtvis måste vi betala för denna bekvämlighet, så vi förväntar oss att maten är god och varm!

Uppenbarligen är vilken restaurang som helst motiverad att hålla sina kunder nöjda. Du kanske blir förvånad över att veta hur mycket arbete som går åt till att driva en takeaway. De flesta använder någon typ av spårningssystem för att hantera beställningar och leveranser. Låt oss titta på datamodellen under ett sådant system. Ta dig ett mellanmål, luta dig tillbaka och njut av artikeln.

Vad bör vi veta om restaurangbranschen?

Att göra mat och leverera till kunder är inte lätt. Först och främst måste du ha talang och kunskap för att laga läckra måltider. Du måste också vara organiserad:allt måste fungera perfekt om dessa måltider ska levereras i tid och till rätt plats!

Innan vi börjar leverera några måltider behöver vi veta:

Vem beställde måltiden
Var och när måltiden ska levereras
Vilka rätter ingår i beställningen
Vilka ingredienser vi behöver för att uppfylla beställningen
Om beställningen redan har betalats för

Vi behöver också spåra leveransstatus och registrera kundfeedback om deras måltid och/eller vår leveransprocess. Dessutom kanske vi vill veta vilka måltider som är mest (eller minst) populära. Och vi bör behålla lite finansiell information också för rapporterings- och analysändamål.

Låt oss anta att vi har en app som våra kunder kan använda för att lägga beställningar för leverans. Det låter dem välja menyalternativ, betala för dem och ange en leveranstid och adress. Hur kan datamodellen under en sådan app se ut?

Datamodellen

Du kan öppna den här modellen i din webbläsare genom att klicka på Edit model in your browser knapp.

Datamodellen består av tre ämnesområden:

Restaurants & customers
Menus
Orders

Vi kommer att presentera varje ämnesområde i den ordning det är listat.

Restauranger och kunder

Restaurants & customers ämnesområdet innehåller tre tabeller som lagrar information om våra restauranger (det kan finnas fler än en), städerna där vi är verksamma och våra kunder.

Både kunder och restauranger finns i städer (eller städer, byar, etc). Därför behöver vi en city lexikon. Den innehåller bara två attribut, city_name och zip_code . Om vi är verksamma i mer än ett land skulle vi också behöva en landslexikon som skulle vara relaterad till den här tabellen, men vi går inte in på det här.

Därefter behöver vi en lista över alla restauranger vi driver. Vi använder restaurant bord för det. För att göra det enkelt lagrar vi bara varje restaurangs address och en referens till city där den finns.

Den sista tabellen i detta ämnesområde är customer tabell. Det är här vi kommer att lagra en lista över alla våra registrerade leveranskunder. Vi kommer att använda data från den här tabellen för att länka kunder till deras beställningar senare i modellen. Kunder behöver naturligtvis inte vara registrerade i vår modell för att göra en beställning, men vi behöver fortfarande denna lista. Vi skulle kunna erbjuda rabatter till registrerade kunder som ett lojalitetsprogram. Eller så kanske vi skulle använda dessa uppgifter för att kontakta kunder med specialerbjudanden. För varje registrerad kund lagrar vi:

customer_name – Kundens fullständiga namn.
city_id – Refererar till city där kunden bor.
address – Kundens adress.
contact_phone – Kundens telefonnummer.
email – E-postadressen som kunden använde under registreringsprocessen.
confirmation_code – En bekräftelsekod som används under registreringsprocessen.
password – Lösenordet som valts av kunden för den här appen.
time_joined – En tidsstämpel för när kunden gick med i vår applikation.

Menyer

Detta ämnesområde innehåller information om våra restaurangers menyer. Låt oss för närvarande anta att alla våra restauranger använder samma meny.

Den första tabellen är category lexikon. Den innehåller bara ett UNIKT attribut, category_name . Det här fältet kommer förmodligen att innehålla de vanliga menykategorierna, som "drycker", "förrätter", "sallader", "smörgåsar", "pizza" etc.

Därefter har vi menu_item tabell. Den listar alla artiklar vi har (eller haft) på någon av våra menyer. För varje vara lagrar vi:

item_name – Ett namn för det föremålet, t.ex. "kycklingsmörgås".
category_id – Refererar till category att föremålet tillhör, t.ex. "smörgåsar".
description – En beskrivning av det föremålet. Detta bör vara detsamma som på den utskrivna menyn.
ingredients – Ingredienserna som används för att tillverka den artikeln och deras kvantiteter. Detta fält kan faktiskt lagra ett recept.
price – Det aktuella priset för en vara (t.ex. en smörgås med kyckling).
active – Om objektet erbjuds på den aktuella menyn.

Om vi vill lagra menyer på flera språk bör vi använda ett tillvägagångssätt som det som presenteras i den här artikeln.

De flesta restauranger har speciella, tidsbegränsade erbjudanden. De kan också ha några erbjudanden under en obegränsad tid. Vi använder offer tabell för dessa. För var och en har vi:

date_active_from och date_active_to – Tillsammans definierar dessa när detta erbjudande är aktivt. Om ett erbjudande har en obegränsad varaktighet eller om det är baserat på timmar snarare än dagar, kommer dessa två attribut att innehålla NULL-värden. Ett exempel på den här typen av erbjudanden är "Under mars månad, köp en curry och få en 50 % rabatt".
time_active_from och time_active_to – Definierar vilken tid på dygnet ett erbjudande är giltigt – t.ex. "Få en gratis kaffe från 6-9 på morgonen varje dag".
offer_price – Priset för det erbjudandet.

Alla menyalternativ som ingår i erbjudanden lagras i in_offer tabell. Den här tabellen innehåller det UNIKA paret offer_id – menu_item_id .

Om våra restauranger har olika menyer måste vi skapa en separat meny för varje restaurang. Vi skulle då behöva koppla menyer och erbjudanden till restauranger som använder främmande nycklar. Detta skulle tillåta oss att ändra menyer och erbjudanden för vilken restaurang som helst utan att påverka de andra. Detta skulle inte bara komplicera databasen; affärsmodellen skulle också bli mer komplex. Det är därför de flesta restaurangkedjorna håller fast vid bara en meny och varför jag bestämde mig för att inte använda den här metoden i den här modellen.

Beställningar

Det sista ämnesområdet i vår modell är Orders ämnesområde. Det är här vi har allt som behövs för att lagra beställningar och deras status.

Den centrala tabellen här är placed_order tabell. Det är bäst att inte bara använda "order" som namn på denna tabell:"order" är ett SQL-nyckelord. Försök att undvika att använda nyckelord som namn på tabeller och kolumner; annars kan du få fel när du skriver frågor. För varje beställning kommer vi att registrera:

restaurant_id – ID för restaurant relaterad till den beställningen.
order_time – En tidsstämpel för när beställningen gjordes.
estimated_delivery_time – En tidsstämpel för den planerade leveransen av denna beställning.
food_ready – En tidsstämpel som anger när beställningsartiklarna förbereddes. Detta kommer att innehålla ett NULL-värde tills maten är tillagad. Vi skulle kunna använda det här attributet för att beräkna tidsskillnaden mellan det ögonblick beställningen gjordes och när maten tillagades. Vi kunde också använda den för att ta reda på hur lång tid som förflutit mellan det att maten var klar tills den levererades. Denna information kan vara till stor hjälp när det gäller att öka personalens effektivitet.
actual_delivery_time – En tidsstämpel för när denna beställning faktiskt levererades. Den kommer att vara NULL tills maten levereras till kunden.
delivery_address – Adressen där beställningen ska levereras.
customer_id – ID för customer vem gjorde den beställningen. Det här attributet kan innehålla ett NULL-värde om beställningen gjordes av någon som inte är en registrerad appanvändare.
price – Priset för alla varor som ingår i den beställningen.
discount – Rabattbeloppet (t.ex. kupong eller lojalitetsrabatt) som tillämpas på priset, om någon.
final_price – Beställningspriset minus rabatten.
comment – Ytterligare kommentarer som lagts in av kunden när beställningen gjordes. Detta kan vara ytterligare leveransinstruktioner eller något annat som kunden tycker är viktigt.
ts – En tidsstämpel för när denna post infogades i tabellen.

in_order Tabellen listar alla artiklar eller specialerbjudanden som ingår i en beställning. För varje post i den här tabellen lagrar vi:

placed_order_id – ID för den relaterade order .
offer_id – Refererar till offer tabell, men endast när ett eller flera erbjudanden ingår i denna beställning. I så fall, menu_item_id attribut kommer att vara NULL.
menu_item_id – Refererar till menu_item tabell, men bara om denna post är relaterad till ett menyalternativ och inte ett erbjudande.
quantity – Hur många erbjudanden eller menyalternativ ingår i denna beställning.
item_price – Priset för ett enstaka erbjudande eller menyalternativ.
price – Det totala priset för denna rad, uttryckt som item_price * quantity .
comment – Eventuella kommentarer som lagts in av kunden som relaterar specifikt till den beställningsvaran, t.ex. "Skär pizza i 8 skivor".

comment tabell låter oss stödja infogning av flera kommentarer relaterade till beställningar. För varje kommentar lagrar vi ID för den relaterade beställningen och ID för kunden. Vi kommer också att lagra en tidsstämpel för när denna kommentar skrevs in. Vi kommer också att markera om den här kommentaren var ett klagomål eller en komplimang; endast en av dessa två kan ställas in samtidigt. Om ingen är inställd kommer vi att behandla den här kommentaren som neutral.

De två sista tabellerna i vår modell är relaterade till status som vi tilldelar beställningar. status_catalog Tabellen innehåller en lista över alla möjliga UNIKA status_name attribut som vi kan tilldela beställningar. order_status Tabellen innehåller alla statusar som är tilldelade order. För varje post i den här tabellen lagrar vi främmande nycklar relaterade till beställning och status och tidsstämpeln när denna status tilldelades.

Vad tycker du om restaurangleveransdatamodellen?

Idag har vi diskuterat en datamodell som kan användas för att organisera, hantera och lagra restaurangleveransbeställningar. Vi kan spåra statusen för varje beställning och några av de ekonomiska detaljerna. Jag har några idéer om hur vi kan göra den här modellen mer robust, men jag skulle gärna höra din åsikt. Vänligen dela det i kommentarsfältet!