Model danych dostawy do restauracji

Głodny, ale nie chcesz gotować? Zadzwoń do restauracji, zamów ulubiony posiłek i przeczytaj o modelu danych, który może zorganizować cały proces.

Pomimo obfitości technologii „oszczędzających czas”, wydaje się, że mamy mniej czasu na zaspokojenie podstawowych potrzeb – takich jak jedzenie. Jeśli chcemy coś zjeść, ale nie mamy czasu (ani umiejętności), aby samemu to ugotować, możemy zamówić jedzenie w restauracji (np. na wynos lub na wynos), która przywiezie nasze posiłki pod same drzwi. Oczywiście za tę wygodę musimy zapłacić, więc oczekujemy, że jedzenie będzie dobre i gorące!

Oczywiście każda restauracja ma motywację do zadowolenia swoich klientów. Możesz być zaskoczony, gdy dowiesz się, ile pracy wymaga przygotowanie jedzenia na wynos. Większość korzysta z jakiegoś systemu śledzenia do zarządzania zamówieniami i dostawami. Przyjrzyjmy się modelowi danych pod jednym z takich systemów. Złap sobie przekąskę, usiądź wygodnie i ciesz się artykułem.

Co powinniśmy wiedzieć o branży restauracyjnej?

Wytwarzanie żywności i dostarczanie jej do klientów nie jest łatwe. Przede wszystkim trzeba mieć talent i wiedzę, aby przygotowywać pyszne posiłki. Musisz też być zorganizowany:wszystko musi działać idealnie, jeśli te posiłki mają być dostarczone na czas i we właściwe miejsce!

Zanim zaczniemy dostarczać posiłki, musimy wiedzieć:

Kto zamówił posiłek
Gdzie i kiedy należy dostarczyć posiłek
Jakie dania są zawarte w zamówieniu
Jakie składniki potrzebujemy do realizacji zamówienia
Jeśli zamówienie zostało już opłacone

Musimy również śledzić statusy dostaw i rejestrować opinie klientów na temat ich posiłków i/lub procesu dostawy. Dodatkowo, może chcemy wiedzieć, które posiłki są najbardziej (lub najmniej) popularne. Powinniśmy również zachować pewne informacje finansowe do celów raportowania i analizy.

Załóżmy, że mamy aplikację, za pomocą której nasi klienci mogą składać zamówienia na dostawę. Pozwala wybrać pozycje z menu, zapłacić za nie, określić czas i adres dostawy. Jak może wyglądać model danych pod taką aplikacją?

Model danych

Możesz otworzyć ten model w swojej przeglądarce, klikając Edit model in your browser przycisk.

Model danych składa się z trzech obszarów tematycznych:

Restaurants & customers
Menus
Orders

Zaprezentujemy każdy obszar tematyczny w kolejności, w jakiej jest wymieniony.

Restauracje i klienci

Restaurants & customers obszar tematyczny zawiera trzy tabele, które przechowują szczegółowe informacje o naszych restauracjach (może być więcej niż jedna), miastach, w których działamy, oraz naszych klientach.

Zarówno klienci, jak i restauracje znajdują się w miastach (lub miasteczkach, wsiach itp.). Dlatego potrzebujemy city słownik. Zawiera tylko dwa atrybuty, city_name i zip_code . Jeśli prowadzimy działalność w więcej niż jednym kraju, potrzebowalibyśmy również słownika krajów, który byłby powiązany z tą tabelą, ale nie będziemy się do tego tutaj zagłębiać.

Następnie potrzebujemy listy wszystkich restauracji, które obsługujemy. Skorzystamy z restaurant stół do tego. Aby wszystko było proste, będziemy przechowywać tylko address każdej restauracji i odniesienie do city gdzie się znajduje.

Ostatnia tabela w tym obszarze tematycznym to customer stół. Tutaj będziemy przechowywać listę wszystkich naszych zarejestrowanych klientów dostarczających przesyłki. Wykorzystamy dane z tej tabeli, aby połączyć klientów z ich zamówieniami w dalszej części modelu. Oczywiście klienci nie muszą być zarejestrowani w naszym modelu, aby złożyć zamówienie, ale wciąż potrzebujemy tej listy. Zarejestrowanym klientom mogliśmy zaoferować zniżki w ramach programu lojalnościowego. A może wykorzystalibyśmy te dane do kontaktowania się z klientami ze specjalnymi ofertami. Dla każdego zarejestrowanego klienta przechowujemy:

customer_name – Imię i nazwisko klienta.
city_id – Odwołuje się do city gdzie mieszka klient.
address – Adres klienta.
contact_phone – Numer telefonu klienta.
email – Adres e-mail, którego klient użył podczas procesu rejestracji.
confirmation_code – Kod potwierdzający używany podczas procesu rejestracji.
password – Hasło wybrane przez klienta do tej aplikacji.
time_joined – Znacznik czasu dołączenia klienta do naszej aplikacji.

item_name – Nazwa tego przedmiotu, np. “kanapka z kurczakiem”.
category_id – Odwołuje się do category do której należy przedmiot, m.in. „kanapki”.
description – Opis tego przedmiotu. Powinno być takie samo jak w wydrukowanym menu.
ingredients – Składniki użyte do produkcji tego przedmiotu i ich ilości. To pole może faktycznie przechowywać przepis.
price – Aktualna cena za jedną sztukę (np. jedną kanapkę z kurczakiem).
active – Jeśli pozycja jest oferowana w bieżącym menu.

Jeśli chcemy przechowywać menu w wielu językach, powinniśmy zastosować podejście podobne do tego przedstawionego w tym artykule.

Większość restauracji ma specjalne, ograniczone czasowo oferty. Mogą również mieć oferty na nieograniczony czas. Skorzystamy z offer tabela dla nich. Dla każdego z nich będziemy mieć:

date_active_from i date_active_to – Razem określają, kiedy ta oferta jest aktywna. Jeśli oferta ma nieograniczony czas trwania lub jest oparta na godzinach, a nie dniach, te dwa atrybuty będą zawierać wartości NULL. Przykładem tego typu oferty jest „W marcu kup jedno curry i zyskaj 50% zniżki na jedno”.
time_active_from i time_active_to – Określa porę dnia, w której oferta jest ważna – m.in. „Każdego dnia od 6 do 9 rano otrzymasz darmową kawę”.
offer_price – Cena tej oferty.

Wszystkie pozycje menu zawarte w ofertach są przechowywane w in_offer stół. Ta tabela zawiera UNIKALNĄ parę offer_id – menu_item_id .

Jeśli nasze restauracje mają różne menu, musimy stworzyć osobne menu dla każdej restauracji. Musielibyśmy wtedy powiązać menu i oferty z restauracjami za pomocą kluczy obcych. To pozwoliłoby nam zmieniać menu i oferty dla dowolnej restauracji bez wpływu na pozostałe. To nie tylko skomplikowałoby bazę danych; model biznesowy również stałby się bardziej złożony. Dlatego większość sieci restauracji trzyma się tylko jednego menu i dlatego zdecydowałem się nie używać tej metody w tym modelu.

Zamówienia

Ostatni obszar tematyczny w naszym modelu to Orders Tematyka. Tutaj będziemy mieć wszystko, co potrzebne do przechowywania zamówień i ich statusów.

Centralna tabela tutaj to placed_order stół. Najlepiej nie używać samego słowa „zamówienie” jako nazwy tej tabeli:„zamówienie” to słowo kluczowe SQL. Staraj się unikać używania słów kluczowych jako nazw tabel i kolumn; w przeciwnym razie możesz otrzymać błędy podczas pisania zapytań. Dla każdego zamówienia odnotujemy:

restaurant_id – Identyfikator restaurant związane z tym zamówieniem.
order_time – Znacznik czasu złożenia zamówienia.
estimated_delivery_time – Znacznik czasowy planowanej dostawy tego zamówienia.
food_ready – Znacznik czasu wskazujący, kiedy pozycje zamówienia zostały przygotowane. Będzie on zawierał wartość NULL, dopóki jedzenie nie zostanie przygotowane. Możemy użyć tego atrybutu do obliczenia różnicy czasu między momentem złożenia zamówienia a przygotowaniem jedzenia. Moglibyśmy również użyć go do sprawdzenia, ile czasu minęło od momentu, gdy jedzenie było gotowe, a kiedy zostało dostarczone. Informacje te mogą być bardzo pomocne w zwiększaniu wydajności personelu.
actual_delivery_time – Znacznik czasu faktycznego dostarczenia zamówienia. Będzie NULL, dopóki jedzenie nie zostanie dostarczone do klienta.
delivery_address – Adres, pod który zamówienie powinno zostać dostarczone.
customer_id – Identyfikator customer kto złożył to zamówienie. Ten atrybut może zawierać wartość NULL, jeśli zamówienie zostało złożone przez kogoś, kto nie jest zarejestrowanym użytkownikiem aplikacji.
price – Cena za wszystkie przedmioty zawarte w tym zamówieniu.
discount – Kwota rabatu (np. kuponu lub rabatu lojalnościowego) zastosowanego do ceny, jeśli taki istnieje.
final_price – Cena zamówienia pomniejszona o rabat.
comment – Dodatkowe uwagi wstawiane przez klienta przy składaniu zamówienia. Mogą to być dodatkowe instrukcje dotyczące dostawy lub cokolwiek innego, co klient uzna za ważne.
ts – Znacznik czasu umieszczenia tego rekordu w tabeli.

in_order tabela zawiera wszystkie pozycje lub oferty specjalne, które są zawarte w zamówieniu. Dla każdego rekordu w tej tabeli będziemy przechowywać:

placed_order_id – Identyfikator powiązanego order .
offer_id – Odwołuje się do offer tabeli, ale tylko wtedy, gdy w tym zamówieniu uwzględniona jest jedna lub więcej ofert. W takim przypadku menu_item_id atrybut będzie NULL.
menu_item_id – Odwołuje się do menu_item tabeli, ale tylko wtedy, gdy ten rekord jest powiązany z pozycją menu, a nie z ofertą.
quantity – Ile ofert lub pozycji menu zawiera to zamówienie.
item_price – Cena pojedynczej oferty lub pozycji menu.
price – Całkowita cena tej linii, wyrażona jako item_price * quantity .
comment – Wszelkie uwagi wstawione przez klienta, które dotyczą konkretnie tej pozycji zamówienia, np. „Proszę pokrój pizzę na 8 kawałków”.

comment tabela pozwala nam na obsługę wstawiania wielu komentarzy związanych z zamówieniami. Dla każdego komentarza będziemy przechowywać identyfikator powiązanego zamówienia oraz identyfikator klienta. Przechowujemy również sygnaturę czasową wprowadzenia tego komentarza. Zaznaczymy również, czy ten komentarz był skargą, czy komplementem; tylko jeden z tych dwóch może być ustawiony na raz. Jeśli żaden nie zostanie ustawiony, potraktujemy ten komentarz jako neutralny.

Ostatnie dwie tabele w naszym modelu są powiązane ze statusami, które przypiszemy do zamówień. status_catalog tabela zawiera listę wszystkich możliwych UNIKATOWYCH status_name atrybuty, które moglibyśmy przypisać do zamówień. order_status tabela zawiera wszystkie statusy, które są przypisane do zamówień. Dla każdego rekordu w tej tabeli będziemy przechowywać klucze obce związane z zamówieniem i statusem oraz sygnaturą czasową, kiedy ten status został przypisany.

Co sądzisz o modelu danych dostaw do restauracji?

Dzisiaj omówiliśmy model danych, który można wykorzystać do organizowania, zarządzania i przechowywania zamówień z dostawą do restauracji. Możemy śledzić status każdego zamówienia i niektóre szczegóły finansowe. Mam kilka pomysłów na ulepszenie tego modelu, ale chętnie poznam Twoją opinię. Udostępnij to w sekcji komentarzy!