Se c'è un modo per ordinare generi alimentari online, perché non usarlo? Questo articolo esamina il modello di dati alla base del sistema di consegna di un negozio di alimentari.
Proviamo ancora una sensazione speciale quando raccogliamo qualcosa dal giardino e poi lo prepariamo subito, ma non è qualcosa che possiamo fare spesso. Il ritmo veloce di oggi non lo consente. A volte, infatti, non ci permette nemmeno di andare in negozio a “picchiare” la nostra spesa. Quindi ha senso risparmiare un po' di tempo e utilizzare un'app per ordinare ciò di cui abbiamo bisogno. Il nostro ordine verrà appena mostrato a casa nostra. Forse non avremo quella speciale sensazione di fresco raccolto, ma ci sarà del cibo sulla nostra tavola.
Il modello di dati alla base di tale applicazione è l'argomento dell'articolo di oggi.
Di cosa abbiamo bisogno per un modello di dati di consegna della spesa?
L'idea di questo modello è che un'applicazione (web, mobile o entrambi) consentirà ai clienti registrati di creare un ordine (composto da prodotti del nostro negozio). Quindi questo ordine verrà consegnato al cliente. Ovviamente memorizzeremo i dati dei clienti e un elenco di tutti i prodotti disponibili per supportare questo.
I clienti possono effettuare più ordini che includono articoli diversi in quantità diverse. Quando l'ordine di un cliente viene ricevuto, i dipendenti del negozio devono essere avvisati in modo che possano trovare e imballare gli articoli necessari. (Ciò potrebbe richiedere uno o più contenitori.) Infine, i contenitori verranno consegnati, insieme o separatamente.
Nell'app stessa, i clienti e i dipendenti dovrebbero essere in grado di inserire note e valutare l'altra parte dopo che la consegna è stata effettuata.
Il modello dei dati
Il modello di dati si compone di tre aree tematiche:
Items & unitsCustomers & employeesOrders
Presenteremo ogni area tematica nell'ordine in cui è elencata.
Sezione 1:Articoli e unità
Inizieremo con gli Items & units argomento. Sebbene sia una piccola parte del nostro modello, contiene due tabelle molto importanti.
L'unit la tabella memorizza le informazioni sulle unità che assegneremo a qualsiasi articolo nel nostro inventario. Per ogni valore in questa tabella, memorizzeremo due valori UNIQUE:unit_name (es. "chilogrammo") e unit_short (es. “kg”). Nota che unit_short è l'abbreviazione di unit_name .
La seconda tabella in questa area tematica è item . Elenca tutti gli articoli che abbiamo in inventario. Per ogni articolo, conserveremo:
item_name– Il nome UNICO che useremo per quell'oggetto.price– Il prezzo corrente di quell'articolo.item_photo– Un collegamento a una foto di questo elemento.description– Descrizione testuale aggiuntiva dell'articolo.unit_id– Fa riferimento all'unitdizionario e denota l'unità utilizzata per misurare quell'elemento.
Si prega di notare che ho omesso alcune cose qui. Il più importante è un flag che indica se un articolo di inventario è attualmente messo in vendita. Perché non abbiamo questo? Richiederebbe almeno un campo aggiuntivo (il flag) e un'altra tabella (per memorizzare le modifiche storiche per ogni articolo). Per semplificare le cose, ho pensato che anche tutti gli articoli che abbiamo in inventario fossero disponibili per la vendita.
La seconda cosa importante che ho omesso è il monitoraggio dello stato del magazzino. La mia ipotesi è che spediamo tutto da un magazzino centrale e che avremo sempre articoli disponibili. Se non disponiamo di un articolo, avviseremo semplicemente il cliente e offriremo loro un articolo simile in sostituzione.
Sezione 2:Clienti e dipendenti
Il Customers & employees l'area tematica contiene tutte le tabelle necessarie per memorizzare i dati dei clienti e dei dipendenti. Useremo queste informazioni nella parte centrale del nostro modello.
Il employee la tabella contiene un elenco di tutti i dipendenti interessati (ad es. gli imballatori di generi alimentari e gli addetti alle consegne). Per ogni dipendente, memorizzeremo il suo first_name e last_name e un employee_code UNICO valore. Sebbene anche la colonna id sia UNICA (e la chiave primaria di questa tabella), è meglio utilizzare un altro valore reale (ad esempio un numero di partita IVA) come identificatore del dipendente. Quindi abbiamo il employee_code campo.
Si noti che non ho incluso i dettagli di accesso dei dipendenti, i ruoli dei dipendenti e un modo per tenere traccia della cronologia dei ruoli. Questi possono essere facilmente aggiunti, come descritto in questo articolo.
Ora aggiungeremo clienti al nostro modello. Ci vorranno altri due tavoli.
I clienti saranno segmentati geograficamente, quindi avremo bisogno di una city dizionario. Per ogni città in cui offriamo la consegna di generi alimentari, memorizzeremo il city_name e il postal_code . Insieme, formano la chiave alternativa di questa tabella.
I clienti sono sicuramente la parte più importante di questo modello; sono loro che avviano l'intero processo. Conserveremo un elenco completo dei nostri clienti nel customer tavolo. Per ogni cliente, memorizzeremo quanto segue:
first_name– Il nome del cliente.last_name– Il cognome del cliente.user_name– Il nome utente selezionato dal cliente durante la configurazione del proprio account.password– La password scelta dal cliente durante la configurazione del proprio account.time_inserted– Il momento in cui questo record è stato inserito nel database.confirmation_code– Un codice che è stato generato durante il codice di registrazione. Questo codice verrà utilizzato per verificare il loro indirizzo email.time_confirmed– Quando è avvenuta la conferma tramite e-mail.contact_email– L'indirizzo e-mail del cliente, utilizzato anche come e-mail di conferma.contact_phone– Il numero di telefono del cliente.city_id– L'ID dellacitydove risiede il cliente.address– L'indirizzo di casa del cliente.delivery_city_id– L'ID dellacitydove deve essere consegnato l'ordine del cliente.delivery_address– L'indirizzo di consegna preferito. Tieni presente che può essere (ma non deve essere) lo stesso dell'indirizzo di casa del cliente.
Sezione 3:Ordini
La parte centrale e più importante di questo modello sono gli Orders argomento. Qui troveremo tutte le tabelle necessarie per effettuare un ordine e per tracciare gli articoli fino alla consegna ai clienti.
L'intero processo inizia quando un cliente effettua un ordine. Un elenco di ogni ordine mai effettuato è nel placed_order tavolo. Ho usato intenzionalmente questo nome e non "order" perché order è una parola chiave riservata SQL. Per ogni ordine, memorizzeremo:
customer_id– L'ID delcustomerche ha effettuato questo ordine.time_placed– Il timestamp in cui è stato effettuato l'ordine.details– Tutti i dettagli relativi a quell'ordine, in formato testuale non strutturato.delivery_city_id– Un riferimento allacitydove deve essere consegnato questo ordine.delivery_address– L'indirizzo a cui deve essere consegnato questo ordine.grade_customer&grade_employee– Gradi assegnati dal dipendente e dal cliente dopo il completamento di un ordine. Fino a quel momento, questo attributo contiene un valore NULL. Il voto di un cliente indica quanto era soddisfatto del nostro servizio; il voto di un dipendente ci fornisce informazioni su cosa aspettarci la prossima volta che il cliente effettua un ordine.
Durante il processo di ordinazione, un cliente selezionerà uno o più articoli. Per ogni articolo, definiranno una quantità desiderata. Un elenco di tutti gli articoli relativi a ciascun ordine è memorizzato in order_item tavolo. Per ogni record in questa tabella, memorizzeremo gli ID per l'ordine correlato (placed_order_id ), elemento (item_id ), la quantità desiderata e il price quando questo ordine è stato effettuato.
Oltre a cosa desiderano essere consegnati, i clienti definiranno anche il tempo di consegna desiderato . Per ogni ordine, creeremo un record nella delivery tavolo. Questo registrerà il delivery_time_planned e inserire ulteriori note testuali. Il placed_order_id l'attributo verrà definito anche quando viene inserito questo record. I restanti due attributi verranno definiti quando assegniamo quella consegna a un dipendente (employee_id ) e quando l'ordine è stato consegnato (delivery_time_actual ).
Anche se potrebbe sembrare che avremo solo una consegna per ordine, potrebbe non essere sempre così. Potrebbe essere necessario effettuare due o più consegne per ordine e questo è il motivo principale per cui ho scelto di inserire i dati di consegna in una nuova tabella.
Quando iniziamo a elaborare un ordine, i dipendenti imballeranno gli articoli in una o più scatole. Ogni box sarà definito UNICAMENTE dal suo box_code e verrà assegnato a una consegna (delivery_id ). Conserveremo anche l'ID del dipendente che ha preparato quella scatola.
Ogni scatola conterrà uno o più articoli. Pertanto, nel item_in_box tabella, dovremo memorizzare i riferimenti alla box tabella (box_id ) e l'item tabella (item_id ), nonché la quantità inserita in quella casella. L'ultimo attributo, is_replacement , indica se un articolo sostituisce un altro articolo. Possiamo aspettarci che un dipendente contatti un cliente prima di mettere un articolo sostitutivo in una scatola. Un risultato di tale azione potrebbe essere che un cliente sia d'accordo con l'articolo sostitutivo; un altro potrebbe essere l'annullamento dell'intero ordine.
Le restanti tre tabelle nel modello sono strettamente correlate a stati e commenti.
Innanzitutto, memorizzeremo tutti i possibili stati nel status_catalog . Ogni stato è UNICAMENTE definito dal suo status_name . Possiamo aspettarci stati come "ordine creato", "ordine effettuato", "articoli imballati", "in transito" e "consegnato".
Gli stati verranno assegnati agli ordini automaticamente (dopo il completamento di alcune parti del processo) o, in alcuni casi, manualmente (ad es. in caso di problemi con l'ordine). Tutti gli stati degli ordini disponibili sono memorizzati in order_status tavolo. Oltre alle chiavi esterne da due tabelle (status_catalog e placed_order ), memorizzeremo il timestamp effettivo quando è stato assegnato questo stato (status_time ) ed eventuali details aggiuntivi in formato testuale.
Il tavolo finale in questo modello sono le notes tavolo. L'idea alla base di questa tabella è inserire tutti i commenti aggiuntivi relativi a un determinato ordine (placed_order_id ). I commenti possono essere inseriti da dipendenti o clienti. Per ogni record, solo uno degli employee_id o customer_id i campi conterranno un valore; l'altro sarà NULL. Conserveremo il momento in cui questa nota è stata inserita nel sistema (note_time ) e il note_text .
Quali modifiche apporteresti al modello dei dati di consegna della spesa?
Oggi abbiamo discusso di un modello di dati in grado di supportare app Web e mobili per la consegna di generi alimentari, sia dal punto di vista del cliente che del dipendente. Come già accennato in questo articolo, ci sono molti modi per migliorare questo modello. Sentiti libero di aggiungere i tuoi suggerimenti. Dicci cosa aggiungeresti a questo modello o cosa rimuoveresti da esso. O forse organizzeresti questa struttura in modo completamente diverso. Fatecelo sapere nella sezione commenti!
