Un modello di dati di consegna al ristorante

Hai fame ma non hai voglia di cucinare? Chiama un ristorante, ordina il tuo pasto preferito e leggi un modello di dati in grado di organizzare l'intero processo.

Nonostante l'abbondanza di tecnologia "risparmio di tempo", sembra che abbiamo meno tempo per soddisfare i bisogni di base, come mangiare. Se vogliamo mangiare qualcosa ma non abbiamo il tempo (o le competenze) per cucinarlo da soli, possiamo ordinare il cibo da un ristorante (cioè da asporto o da asporto), che porterà i nostri pasti direttamente alle nostre porte. Ovviamente dobbiamo pagare per questa comodità, quindi ci aspettiamo che il cibo sia buono e caldo!

Ovviamente, qualsiasi ristorante è motivato a soddisfare i propri clienti. Potresti essere sorpreso di sapere quanto lavoro è necessario per gestire un cibo da asporto. La maggior parte utilizza un qualche tipo di sistema di tracciamento per gestire gli ordini e le consegne. Diamo un'occhiata al modello di dati sotto uno di questi sistemi. Fatti uno spuntino, siediti e goditi l'articolo.

Cosa dovremmo sapere sull'attività di ristorazione?

Fare il cibo e consegnarlo ai clienti non è facile. Prima di tutto, devi avere talento e conoscenza per preparare pasti deliziosi. Devi anche essere organizzato:tutto deve funzionare perfettamente se questi pasti devono essere consegnati in tempo e nel posto giusto!

Prima di iniziare a consegnare i pasti, dobbiamo sapere:

Chi ha ordinato il pasto
Dove e quando consegnare il pasto
Quali piatti sono inclusi nell'ordine
Di quali ingredienti abbiamo bisogno per evadere l'ordine
Se l'ordine è già stato pagato

Dobbiamo anche tenere traccia degli stati di consegna e registrare il feedback dei clienti sul pasto e/o sul nostro processo di consegna. Inoltre, forse vogliamo sapere quali pasti sono i più (o meno) popolari. E dovremmo anche conservare alcune informazioni finanziarie a scopo di reportistica e analisi.

Supponiamo di avere un'app che i nostri clienti possono utilizzare per effettuare ordini per la consegna. Consente loro di scegliere le voci di menu, pagarle e specificare un tempo di consegna e un indirizzo. Come potrebbe essere il modello di dati sotto un'app del genere?

Il modello dei dati

Puoi aprire questo modello nel tuo browser facendo clic su Edit model in your browser pulsante.

Il modello di dati si compone di tre aree tematiche:

Restaurants & customers
Menus
Orders

Presenteremo ogni area tematica nell'ordine in cui è elencata.

Ristoranti e Clienti

Il Restaurants & customers l'area tematica contiene tre tabelle che memorizzano i dettagli sui nostri ristoranti (possono essercene più di uno), le città in cui operiamo e i nostri clienti.

Sia i clienti che i ristoranti si trovano nelle città (o paesi, paesi, ecc.). Pertanto, abbiamo bisogno di una city dizionario. Contiene solo due attributi, city_name e zip_code . Se operiamo in più di un paese, avremmo bisogno anche di un dizionario del paese che sia correlato a questa tabella, ma non ne parleremo qui.

Successivamente, abbiamo bisogno di un elenco di tutti i ristoranti in cui operiamo. Useremo il restaurant tavolo per quello. Per semplificare le cose, memorizzeremo solo l'address di ogni ristorante e un riferimento alla city dove si trova.

L'ultima tabella in questa area tematica è il customer tavolo. Qui è dove memorizzeremo un elenco di tutti i nostri clienti di consegna registrati. Utilizzeremo i dati di questa tabella per collegare i clienti ai loro ordini più avanti nel modello. Naturalmente, i clienti non devono essere registrati nel nostro modello per effettuare un ordine, ma abbiamo comunque bisogno di questo elenco. Potremmo offrire sconti ai clienti registrati come programma fedeltà. O forse useremmo questi dati per contattare i clienti con offerte speciali. Per ogni cliente registrato, memorizzeremo:

customer_name – Il nome completo del cliente.
city_id – Fa riferimento alla city dove vive il cliente.
address – L'indirizzo del cliente.
contact_phone – Il numero di telefono del cliente.
email – L'indirizzo email utilizzato dal cliente durante il processo di registrazione.
confirmation_code – Un codice di conferma utilizzato durante il processo di registrazione.
password – La password selezionata dal cliente per questa app.
time_joined – Un timestamp di quando il cliente si è unito alla nostra applicazione.

item_name – Un nome per quell'elemento, ad es. “panino con pollo”.
category_id – Fa riferimento alla category a cui appartiene l'oggetto, ad es. “panini”.
description – Una descrizione di quell'elemento. Dovrebbe essere lo stesso del menu stampato.
ingredients – Gli ingredienti utilizzati per produrre quell'articolo e le loro quantità. Questo campo potrebbe effettivamente memorizzare una ricetta.
price – Il prezzo corrente per un articolo (ad es. un sandwich di pollo).
active – Se l'elemento è offerto nel menu corrente.

Se vogliamo memorizzare i menu in più lingue, dovremmo utilizzare un approccio come quello presentato in questo articolo.

La maggior parte dei ristoranti offre offerte speciali a tempo limitato. Potrebbero anche avere alcune offerte per un periodo di tempo illimitato. Utilizzeremo l'offer tabella per questi. Per ognuno avremo:

date_active_from e date_active_to – Insieme, definiscono quando questa offerta è attiva. Se un'offerta ha una durata illimitata o se è basata su ore anziché su giorni, questi due attributi conterranno valori NULL. Un esempio di questo tipo di offerta è "Durante il mese di marzo, acquista un curry e ottieni uno sconto del 50%".
time_active_from e time_active_to – Definisce l'ora del giorno in cui un'offerta è valida – ad es. “Ricevi un caffè gratis tutti i giorni dalle 6:00 alle 9:00”.
offer_price – Il prezzo di quell'offerta.

Tutte le voci di menu incluse nelle offerte sono memorizzate nel in_offer tavolo. Questa tabella contiene la coppia UNICA di offer_id – menu_item_id .

Se i nostri ristoranti hanno menu diversi, dobbiamo creare un menu separato per ogni ristorante. Avremmo quindi bisogno di mettere in relazione menu e offerte con i ristoranti utilizzando chiavi esterne. Questo ci consentirebbe di modificare i menu e le offerte di qualsiasi ristorante senza influire sugli altri. Questo non complicherebbe solo il database; anche il modello di business diventerebbe più complesso. Questo è il motivo per cui la maggior parte delle catene di ristoranti si attiene a un solo menu e perché ho deciso di non utilizzare questo metodo in questo modello.

Ordini

L'ultima area tematica del nostro modello è Orders argomento. Qui è dove avremo tutto il necessario per archiviare gli ordini e il loro stato.

La tabella centrale qui è il placed_order tavolo. È meglio non usare solo "order" come nome di questa tabella:"order" è una parola chiave SQL. Cerca di evitare di usare parole chiave come nomi per tabelle e colonne; in caso contrario, potresti ricevere errori durante la scrittura di query. Per ogni ordine, registreremo:

restaurant_id – L'ID del restaurant relativi a quell'ordine.
order_time – Un timestamp di quando è stato effettuato l'ordine.
estimated_delivery_time – Un timestamp della consegna pianificata di questo ordine.
food_ready – Un timestamp che indica quando gli articoli dell'ordine sono stati preparati. Questo conterrà un valore NULL fino a quando il cibo non sarà preparato. Potremmo utilizzare questo attributo per calcolare la differenza di tempo tra il momento in cui è stato effettuato l'ordine e il momento in cui il cibo è stato preparato. Potremmo anche usarlo per trovare quanto tempo è trascorso tra quando il cibo era pronto e quando è stato consegnato. Queste informazioni possono essere molto utili in termini di aumento dell'efficienza del personale.
actual_delivery_time – Un timestamp di quando questo ordine è stato effettivamente consegnato. Sarà NULLO fino alla consegna del cibo al cliente.
delivery_address – L'indirizzo a cui consegnare l'ordine.
customer_id – L'ID del customer chi ha fatto quell'ordine. Questo attributo potrebbe contenere un valore NULL se l'ordine è stato effettuato da qualcuno che non è un utente registrato dell'app.
price – Il prezzo di tutti gli articoli inclusi in quell'ordine.
discount – L'importo dello sconto (ad es. coupon o sconto fedeltà) applicato al prezzo, se presente.
final_price – Il prezzo dell'ordine meno lo sconto.
comment – Commenti aggiuntivi inseriti dal cliente al momento dell'ordine. Potrebbero essere istruzioni di consegna aggiuntive o qualsiasi altra cosa che il cliente ritiene importante.
ts – Un timestamp di quando questo record è stato inserito nella tabella.

Il in_order la tabella elenca tutti gli articoli o le offerte speciali inclusi in un ordine. Per ogni record in questa tabella, memorizzeremo:

placed_order_id – L'ID del relativo order .
offer_id – Fa riferimento all'offer tabella, ma solo quando una o più offerte sono incluse in questo ordine. In tal caso, il menu_item_id l'attributo sarà NULL.
menu_item_id – Fa riferimento al menu_item tabella, ma solo se questo record è correlato a una voce di menu e non a un'offerta.
quantity – Quante offerte o voci di menu sono incluse in questo ordine.
item_price – Il prezzo di una singola offerta o voce di menu.
price – Il prezzo totale di questa riga, espresso come item_price * quantity .
comment – Eventuali commenti inseriti dal cliente che si riferiscono specificamente a tale articolo dell'ordine, ad es. “Per favore, taglia la pizza in 8 fette”.

Il comment tabella permette di supportare l'inserimento di più commenti relativi agli ordini. Per ogni commento memorizzeremo l'ID del relativo ordine e l'ID del cliente. Conserveremo anche un timestamp di quando è stato inserito questo commento. Indicheremo anche se questo commento è stato un reclamo o un complimento; solo uno di questi due può essere impostato alla volta. Se non ne viene impostato nessuno, tratteremo questo commento come neutro.

Le ultime due tabelle nel nostro modello sono relative agli stati che assegneremo agli ordini. Il status_catalog la tabella contiene un elenco di tutti i possibili UNIQUE status_name attributi che potremmo assegnare agli ordini. Il order_status la tabella contiene tutti gli stati assegnati agli ordini. Per ogni record in questa tabella, memorizzeremo le chiavi esterne relative all'ordine e allo stato e il timestamp quando è stato assegnato questo stato.

Cosa ne pensi del modello di dati di consegna al ristorante?

Oggi abbiamo discusso di un modello di dati che potrebbe essere utilizzato per organizzare, gestire e archiviare gli ordini di consegna al ristorante. Siamo in grado di monitorare lo stato di ogni ordine e alcuni dettagli finanziari. Ho alcune idee su come potremmo rendere questo modello più robusto, ma sarei felice di sentire la tua opinione. Per favore condividilo nella sezione commenti!