En modell för livsmedelsleveransdata

Om det finns ett sätt att beställa mat online, varför inte använda det? Den här artikeln undersöker datamodellen bakom en livsmedelsbutiks leveranssystem.

Vi får fortfarande en speciell känsla av att plocka något från trädgården och sedan förbereda det direkt – men det är inte något vi kan göra ofta. Dagens snabba tempo tillåter inte det. I själva verket tillåter det ibland inte ens att vi går till butiken för att "plocka" våra matvaror. Så det är vettigt att spara lite tid och använda en app för att beställa det vi behöver. Vår beställning kommer precis att dyka upp hemma hos oss. Vi kanske inte får den där speciella nyplockade känslan, men det kommer att finnas mat på vårt bord.

Datamodellen bakom en sådan applikation är ämnet för dagens artikel.

Vad behöver vi för en datamodell för livsmedelsleverans?

Tanken med denna modell är att en applikation (webb, mobil eller båda) gör det möjligt för registrerade kunder att skapa en beställning (som består av produkter från vår butik). Därefter kommer denna beställning att levereras till kunden. Vi kommer självklart att lagra kunddata och en lista över alla tillgängliga produkter för att stödja detta.

Kunder kan lägga flera beställningar som innehåller olika varor i olika kvantiteter. När en kunds beställning tas emot ska butiksanställda meddelas så att de kan hitta och packa de nödvändiga föremålen. (Detta kan kräva en eller flera containrar.) Slutligen kommer containrarna att levereras, antingen tillsammans eller separat.

I själva appen ska kunder och anställda kunna lägga in anteckningar och betygsätta motparten efter att leveransen är gjord.

Datamodellen

Datamodellen består av tre ämnesområden:

• Items & units
• Customers & employees
• Orders

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

Avsnitt 1:Artiklar och enheter

Vi börjar med Items & units ämnesområde. Även om det är en liten del av vår modell, innehåller den två mycket viktiga tabeller.

unit Tabellen lagrar information om de enheter vi kommer att tilldela alla objekt i vårt lager. För varje värde i den här tabellen lagrar vi två UNIKA värden:unit_name (t.ex. "kilogram") och unit_short (t.ex. "kg"). Lägg märke till att unit_short är förkortningen för unit_name .

Den andra tabellen i detta ämnesområde är item . Den listar alla artiklar vi har i lager. För varje vara lagrar vi:

• item_name – Det UNIKA namn vi kommer att använda för det föremålet.
• price – Det aktuella priset för den artikeln.
• item_photo – En länk till ett foto av detta föremål.
• description – Ytterligare textbeskrivning av föremålet.
• unit_id – Refererar till unit ordbok och anger den enhet som används för att mäta objektet.

Observera att jag har utelämnat några saker här. Den viktigaste är en flagga som anger om en inventarievara för närvarande bjuds ut till försäljning. Varför har vi inte detta? Det skulle kräva minst ett ytterligare fält (flaggan) samt en annan tabell (för att lagra historiska ändringar för varje objekt). För att göra det enkelt antog jag att alla föremål vi har i lager också är tillgängliga att sälja.

Det andra viktiga jag utelämnade är att spåra lagerstatusen. Mitt antagande är att vi skickar allt från ett centrallager och att vi alltid kommer att ha tillgängliga varor. Om vi ​​inte har en vara kommer vi helt enkelt att meddela kunden och erbjuda dem en liknande vara som ersättning.

Avsnitt 2:Kunder och anställda

Customers & employees Ämnesområdet innehåller alla tabeller som behövs för att lagra kund- och personaldata. Vi kommer att använda denna information i den centrala delen av vår modell.

employee Tabellen innehåller en lista över alla relevanta anställda (t.ex. livsmedelsförpackare och leveranspersonal). För varje anställd lagrar vi deras first_name och last_name och en UNIK employee_code värde. Även om id-kolumnen också är UNIK (och den här tabellens primära nyckel), är det bättre att använda ett annat verkligt värde (t.ex. ett momsnummer) som en anställds identifierare. Därför har vi employee_code fältet.

Observera att jag inte har inkluderat anställds inloggningsuppgifter, anställdsroller och ett sätt att spåra rollhistorik. Dessa kan enkelt läggas till, som beskrivs i den här artikeln.

Nu lägger vi till kunder till vår modell. Detta kommer att ta ytterligare två tabeller.

Kunderna kommer att segmenteras geografiskt, så vi behöver en city lexikon. För varje stad där vi erbjuder matleverans lagrar vi city_name och postal_code . Tillsammans bildar dessa den alternativa nyckeln i denna tabell.

Kunderna är definitivt den viktigaste delen av denna modell; det är de som initierar hela processen. Vi lagrar en komplett lista över våra kunder i customer tabell. För varje kund lagrar vi följande:

• first_name – Kundens förnamn.
• last_name – Kundens efternamn.
• user_name – Användarnamnet som kunden valde när han satte upp sitt konto.
• password – Lösenordet som kunden valde när han satte upp sitt konto.
• time_inserted – Det ögonblick då denna post infogades i databasen.
• confirmation_code – En kod som genererades under registreringskoden. Denna kod kommer att användas för att verifiera deras e-postadress.
• time_confirmed – När e-postbekräftelsen skedde.
• contact_email – Kundens e-postadress, som också används som bekräftelsemail.
• contact_phone – Kundens telefonnummer.
• city_id – ID för city där kunden bor.
• address – Kundens hemadress.
• delivery_city_id – ID för city där kundens beställning ska levereras.
• delivery_address – Den föredragna leveransadressen. Observera att detta kan vara (men behöver inte vara) samma som kundens hemadress.

Avsnitt 3:Beställningar

Den centrala och viktigaste delen av denna modell är Orders ämnesområde. Här hittar vi alla tabeller som behövs för att göra en beställning och för att spåra varor tills de levereras till kunder.

Hela processen startar när en kund lägger en beställning. En lista över alla beställningar som någonsin gjorts finns i placed_order tabell. Jag har avsiktligt använt detta namn och inte "order" eftersom order är ett reserverat SQL-nyckelord. För varje beställning lagrar vi:

• customer_id – ID för customer som gjorde den här beställningen.
• time_placed – Tidsstämpeln när denna beställning gjordes.
• details – Alla detaljer relaterade till den beställningen, i ostrukturerat textformat.
• delivery_city_id – En referens till city där denna beställning ska levereras.
• delivery_address – Adressen där denna beställning ska levereras.
• grade_customer &grade_employee – Betyg ges av medarbetare och kund efter genomförd beställning. Fram till det ögonblicket innehåller detta attribut ett NULL-värde. En kunds betyg anger hur nöjda de var med vår tjänst; en anställds betyg ger oss information om vad vi kan förvänta oss nästa gång kunden gör en beställning.

Under processen att lägga en beställning kommer en kund att välja en eller flera varor. För varje artikel kommer de att definiera en önskad kvantitet. En lista över alla artiklar relaterade till varje beställning lagras i order_item tabell. För varje post i den här tabellen lagrar vi ID:n för den relaterade beställningen (placed_order_id ), objekt (item_id ), önskad kvantitet och price när denna beställning gjordes.

Förutom vad de vill ha levererat, kommer kunder också att definiera sin önskade leveranstid tid . För varje beställning skapar vi en post i delivery tabell. Detta kommer att registrera delivery_time_planned och infoga ytterligare textanteckningar. placed_order_id attribut kommer också att definieras när denna post infogas. De återstående två attributen kommer att definieras när vi tilldelar leveransen till en anställd (employee_id ) och när beställningen levererades (delivery_time_actual ).

Även om det kan se ut som att vi bara kommer att ha en leverans per beställning, kanske det inte alltid är fallet. Vi kan behöva göra två eller fler leveranser per beställning, och det är den främsta anledningen till att jag valde att lägga in leveransdata i en ny tabell.

När vi börjar behandla en beställning kommer anställda att packa varorna i en eller flera lådor. Varje box kommer att definieras UNIKT av dess box_code och kommer att tilldelas en leverans (delivery_id ). Vi lagrar också ID:t för den anställde som förberedde lådan.

Varje ruta kommer att innehålla en eller flera föremål. Därför i item_in_box tabell måste vi lagra referenser till box tabell (box_id ) och item tabell (item_id ), samt den mängd som placeras i den lådan. Det sista attributet, is_replacement , anger om en vara är en ersättning för en annan vara. Vi kan förvänta oss att en anställd kontaktar en kund innan han lägger en ersättningsvara i en kartong. Ett resultat av den åtgärden kan vara att en kund accepterar ersättningsartikeln; en annan kan vara att annullera hela beställningen.

De återstående tre tabellerna i modellen är nära relaterade till status och kommentarer.

Först lagrar vi alla möjliga statusar i status_catalog . Varje status definieras UNIKT av dess status_name . Vi kan förvänta oss statuser som "beställning skapad", "beställning placerad", "varor packade", "på transport" och "levererad".

Statuser kommer att tilldelas beställningar antingen automatiskt (efter att vissa delar av processen har slutförts) eller, i vissa fall, manuellt (t.ex. om det finns ett problem med beställningen). Alla tillgängliga orderstatusar lagras i order_status tabell. Förutom främmande nycklar från två tabeller (status_catalog och placed_order ), lagrar vi den faktiska tidsstämpeln när denna status tilldelades (status_time ) och eventuella ytterligare details i textformat.

Den sista tabellen i denna modell är notes tabell. Tanken bakom denna tabell är att infoga alla ytterligare kommentarer relaterade till en given beställning (placed_order_id ). Kommentarer kan infogas av anställda eller kunder. För varje post, endast en av employee_id eller customer_id fält kommer att innehålla ett värde; den andra kommer att vara NULL. Vi lagrar ögonblicket då denna anteckning infogades i systemet (note_time ) och note_text .

Vilka ändringar skulle du göra i modellen för livsmedelsleveransdata?

Idag diskuterade vi en datamodell som skulle kunna stödja webb- och mobilappar för livsmedelsleverans – både ur kundens och medarbetarperspektivet. Som redan nämnts i den här artikeln finns det många sätt att förbättra denna modell. Lägg gärna till dina förslag. Berätta för oss vad du skulle lägga till den här modellen eller ta bort från den. Eller så kanske du skulle organisera den här strukturen helt annorlunda. Låt oss veta i kommentarsfältet!