Hvis der er en måde at bestille dagligvarer online, hvorfor så ikke bruge den? Denne artikel undersøger datamodellen bag en dagligvarebutiks leveringssystem.
Vi får stadig en særlig følelse af at plukke noget fra haven og så forberede det med det samme - men det er ikke noget, vi kan gøre ofte. Dagens hurtige tempo tillader det ikke. Faktisk tillader det nogle gange os ikke engang at gå i butikken for at "plukke" vores dagligvarer. Så det giver mening at spare os selv for lidt tid og bruge en app til at bestille det, vi har brug for. Vores ordre vil bare dukke op i vores hjem. Måske får vi ikke den særlige friskplukkede følelse, men der vil være mad på vores bord.
Datamodellen bag en sådan applikation er emnet for dagens artikel.
Hvad har vi brug for til en købmandsleveringsdatamodel?
Ideen med denne model er, at en applikation (web, mobil eller begge dele) giver registrerede kunder mulighed for at oprette en ordre (bestående af produkter fra vores butik). Så vil denne ordre blive leveret til kunden. Vi vil naturligvis gemme kundedata og en liste over alle tilgængelige produkter for at understøtte dette.
Kunder kan placere flere ordrer, der inkluderer forskellige varer i forskellige mængder. Når en kundes ordre modtages, skal butiksansatte underrettes, så de kan finde og pakke de nødvendige varer. (Dette kan kræve en eller flere containere.) Til sidst vil containerne blive leveret, enten samlet eller hver for sig.
I selve appen skal kunder og medarbejdere kunne indsætte noter og bedømme modparten efter leveringen er foretaget.
Datamodellen
Datamodellen består af tre emneområder:
Elementer og enhederKunder og medarbejdereOrdrer
Vi præsenterer hvert emneområde i den rækkefølge, det er angivet.
Afsnit 1:Elementer og enheder
Vi starter med
enheden tabel gemmer oplysninger om de enheder, vi vil tildele til enhver vare i vores beholdning. For hver værdi i denne tabel gemmer vi to UNIKKE værdier:unit_name (f.eks. "kilogram") og unit_short (f.eks. "kg"). Bemærk, at unit_short er forkortelsen for unit_name .
Den anden tabel i dette emneområde er item . Den viser alle de varer, vi har på lager. For hver vare gemmer vi:
varenavn– Det UNIKKE navn, vi vil bruge til den vare.pris– Den aktuelle pris på den pågældende vare.item_photo– Et link til et foto af denne vare.beskrivelse– Yderligere tekstbeskrivelse af varen.enheds-id– Henviser tilenhedenordbog og angiver den enhed, der bruges til at måle det pågældende element.
Bemærk venligst, at jeg har udeladt et par ting her. Den vigtigste er et flag, der angiver, om en inventarvare i øjeblikket udbydes til salg. Hvorfor har vi ikke dette? Det ville kræve mindst et ekstra felt (flaget) samt en anden tabel (for at gemme historiske ændringer for hvert element). For at gøre tingene enkle, gik jeg ud fra, at alle de varer, vi har på lager, også er tilgængelige til salg.
Den anden vigtige ting, jeg undlod, er at spore lagerstatus. Min antagelse er, at vi sender alt fra ét centrallager, og at vi altid har ledige varer. Hvis vi ikke har en vare, giver vi blot kunden besked og tilbyder dem en lignende vare som erstatning.
Afsnit 2:Kunder og medarbejdere
Kunder og medarbejdere emneområdet indeholder alle de tabeller, der er nødvendige for at gemme kunde- og medarbejderdata. Vi bruger disse oplysninger i den centrale del af vores model.
medarbejderen tabel indeholder en liste over alle relevante medarbejdere (f.eks. købmandspakkerne og udbringerne). For hver medarbejder gemmer vi deres first_name og efternavn og en UNIK medarbejderkode værdi. Selvom id-kolonnen også er UNIK (og denne tabels primære nøgle), er det bedre at bruge en anden værdi i den virkelige verden (f.eks. et momsnummer) som medarbejder-id. Således har vi employee_code felt.
Bemærk, at jeg ikke har inkluderet medarbejders loginoplysninger, medarbejderroller og en måde at spore rollehistorik på. Disse kan nemt tilføjes, som beskrevet i denne artikel.
Nu tilføjer vi kunder til vores model. Dette vil tage to borde mere.
Kunder vil blive segmenteret geografisk, så vi skal bruge en by ordbog. For hver by, hvor vi tilbyder levering af dagligvarer, gemmer vi city_name og postal_code . Tilsammen danner disse den alternative nøgle i denne tabel.
Kunderne er absolut den vigtigste del af denne model; det er dem, der sætter hele processen i gang. Vi gemmer en komplet liste over vores kunder i kunden bord. For hver kunde gemmer vi følgende:
fornavn– Fornavnet på kunden.efternavn– Kundens efternavn.brugernavn– Det brugernavn, kunden valgte, da han oprettede sin konto.adgangskode– Den adgangskode, kunden valgte, da han oprettede sin konto.tid_indsat– Det øjeblik, hvor denne post blev indsat i databasen.bekræftelseskode– En kode, der blev genereret under registreringskoden. Denne kode vil blive brugt til at bekræfte deres e-mailadresse.tidsbekræftet– Da e-mailbekræftelsen skete.contact_email– Kundens e-mailadresse, som også bruges som bekræftelsesmail.contact_phone– Kundens telefonnummer.by_id– ID'et forbyenhvor kunden bor.adresse– Kundens hjemmeadresse.leveringsby_id– ID'et forbyenhvor kundens ordre skal leveres.leveringsadresse– Den foretrukne leveringsadresse. Bemærk, at dette kan være (men ikke behøver at være) det samme som kundens hjemmeadresse.
Afsnit 3:Ordrer
Den centrale og vigtigste del af denne model er ordrerne emneområde. Her finder vi alle de tabeller, der er nødvendige for at afgive en ordre og spore varer, indtil de er leveret til kunderne.
Hele processen starter, når en kunde afgiver en ordre. En liste over alle ordrer, der nogensinde er afgivet, er i placed_order bord. Jeg har med vilje brugt dette navn og ikke "ordre", fordi ordre er et SQL-reserveret nøgleord. For hver ordre gemmer vi:
kunde-id– ID'et forkundender afgav denne ordre.tidspunkt_placeret– Tidsstemplet, da denne ordre blev afgivet.detaljer– Alle detaljer relateret til den ordre, i ustruktureret tekstformat.leveringsby_id– En reference tilbyenhvor denne ordre skal leveres.leveringsadresse– Adressen, hvor denne ordre skal leveres.grade_customer&grade_employee– Karakterer givet af medarbejderen og kunden efter en ordre er gennemført. Indtil det øjeblik indeholder denne attribut en NULL-værdi. En kundes karakter angiver, hvor tilfredse de var med vores service; en medarbejders karakter giver os information om, hvad vi kan forvente næste gang, kunden afgiver en ordre.
Under processen med at afgive en ordre, vil en kunde vælge en eller flere varer. For hver vare vil de definere en ønsket mængde. En liste over alle varer relateret til hver ordre er gemt i order_item bord. For hver post i denne tabel gemmer vi ID'er for den relaterede ordre (placed_order_id ), element (item_id ), den ønskede mængde og prisen når denne ordre blev afgivet.
Ud over hvad de ønsker leveret, vil kunder også definere deres ønskede leveringstidspunkt . For hver ordre opretter vi én post i levering bord. Dette vil registrere den delivery_time_planned og indsæt yderligere tekstnoter. placed_order_id attribut vil også blive defineret, når denne post indsættes. De resterende to attributter vil blive defineret, når vi tildeler denne levering til en medarbejder (employee_id ) og hvornår ordren blev leveret (delivery_time_actual ).
Selvom det kan se ud til, at vi kun har én levering pr. ordre, er det måske ikke altid tilfældet. Vi skal muligvis lave to eller flere leveringer pr. ordre, og det er hovedårsagen til, at jeg valgte at lægge leveringsdata i en ny tabel.
Når vi begynder at behandle en ordre, vil medarbejderne pakke varerne i en eller flere kasser. Hver boks vil blive defineret UNIKT af dens box_code og vil blive tildelt en levering (delivery_id ). Vi gemmer også ID'et på den medarbejder, der har forberedt den boks.
Hver boks vil indeholde en eller flere elementer. Derfor i item_in_box tabel, skal vi gemme referencer til boksen tabel (box_id ) og emnet tabel (item_id ), samt mængden placeret i den pågældende boks. Den sidste attribut, is_replacement , angiver, om en vare er en erstatning for en anden vare. Vi kan forvente, at en medarbejder kontakter en kunde, inden den lægger en erstatningsvare i en æske. Et resultat af denne handling kunne være, at en kunde accepterer erstatningsvaren; en anden kunne være annullering af hele ordren.
De resterende tre tabeller i modellen er tæt forbundet med statusser og kommentarer.
Først gemmer vi alle mulige statusser i status_kataloget . Hver status er UNIKT defineret af dens status_name . Vi kan forvente statusser som "ordre oprettet", "ordre placeret", "varer pakket", "i transit" og "leveret".
Statusser vil blive tildelt til ordrer enten automatisk (efter nogle dele af processen er afsluttet) eller i nogle tilfælde manuelt (f.eks. hvis der er et problem med ordren). Alle tilgængelige ordrestatusser gemmes i order_status bord. Udover fremmednøgler fra to tabeller (status_catalog og placed_order ), gemmer vi det faktiske tidsstempel, da denne status blev tildelt (status_time ) og eventuelle yderligere detaljer i tekstformat.
Den sidste tabel i denne model er noterne bord. Ideen bag denne tabel er at indsætte alle yderligere kommentarer relateret til en given ordre (placed_order_id ). Kommentarer kan indsættes af medarbejdere eller kunder. For hver post, kun én af employee_id eller customer_id felter vil indeholde en værdi; den anden vil være NULL. Vi gemmer det øjeblik, hvor denne note blev indsat i systemet (note_time ) og note_text .
Hvilke ændringer ville du foretage i købmandsleveringsdatamodellen?
I dag diskuterede vi en datamodel, der kunne understøtte web- og mobilapps til levering af dagligvarer – både fra kundens og medarbejdernes perspektiv. Som allerede nævnt i denne artikel, er der mange måder at forbedre denne model på. Tilføj gerne dine forslag. Fortæl os, hvad du vil tilføje til denne model eller fjerne fra den. Eller måske ville du organisere denne struktur helt anderledes. Fortæl os det i kommentarfeltet!