Datový model rozvozu restaurace

Máte hlad, ale nechce se vám vařit? Zavolejte do restaurace, objednejte si své oblíbené jídlo a přečtěte si o datovém modelu, který dokáže zorganizovat celý proces.

Navzdory velkému množství „časově úsporných“ technologií se zdá, že máme méně času na uspokojení základních potřeb – jako je jídlo. Pokud chceme něco sníst, ale nemáme čas (nebo dovednosti) to sami uvařit, můžeme si jídlo objednat v restauraci (tj. jídlo s sebou nebo s sebou), která nám jídlo doveze až ke dveřím. Za tuto vymoženost si samozřejmě musíme zaplatit, takže očekáváme, že jídlo bude dobré a teplé!

Je zřejmé, že každá restaurace je motivována ke spokojenosti svých zákazníků. Možná budete překvapeni, když zjistíte, kolik práce dá provozování jídla s sebou. Většina používá nějaký typ sledovacího systému pro správu objednávek a dodávek. Podívejme se na datový model pod jedním takovým systémem. Vezměte si svačinu, posaďte se a užijte si článek.

Co bychom měli vědět o restauraci?

Vyrobit jídlo a dodat je zákazníkům není jednoduché. K přípravě chutných jídel musíte mít v první řadě talent a znalosti. Musíte být také organizováni:vše musí perfektně fungovat, pokud mají být tato jídla doručena včas a na správné místo!

Než začneme dodávat jídla, potřebujeme vědět:

Kdo objednal jídlo
Kam a kdy má být jídlo doručeno
Jaká jídla jsou zahrnuta v objednávce
Jaké ingredience potřebujeme ke splnění objednávky
Pokud již byla objednávka zaplacena

Potřebujeme také sledovat stavy doručení a zaznamenávat zpětnou vazbu zákazníků ohledně jejich jídla a/nebo našeho procesu doručení. Navíc možná chceme vědět, která jídla jsou nejoblíbenější (nebo nejméně). A také bychom si měli ponechat nějaké finanční informace pro účely výkaznictví a analýzy.

Předpokládejme, že máme aplikaci, kterou mohou naši zákazníci používat k zadávání objednávek na doručení. Umožňuje jim vybrat si položky nabídky, zaplatit za ně a určit čas doručení a adresu. Jak by mohl vypadat datový model pod takovou aplikací?

Datový model

Tento model můžete otevřít ve svém prohlížeči kliknutím na Edit model in your browser knoflík.

Datový model se skládá ze tří tematických oblastí:

Restaurants & customers
Menus
Orders

Každou oblast představíme v pořadí, v jakém je uvedena.

Restaurace a zákazníci

Restaurants & customers předmětová oblast obsahuje tři tabulky, které ukládají podrobnosti o našich restauracích (může jich být více), městech, kde působíme, a našich zákaznících.

Zákazníci i restaurace se nacházejí ve městech (nebo městech, vesnicích atd.). Proto potřebujeme city slovník. Obsahuje pouze dva atributy, city_name a zip_code . Pokud působíme ve více než jedné zemi, potřebovali bychom také národní slovník, který by se vztahoval k této tabulce, ale tím se zde nebudeme zabývat.

Dále potřebujeme seznam všech restaurací, které provozujeme. Využijeme restaurant stůl na to. Abychom to zjednodušili, uložíme pouze address každé restaurace a odkaz na city kde se nachází.

Poslední tabulkou v této předmětové oblasti je customer stůl. Zde budeme ukládat seznam všech našich registrovaných zákazníků. Údaje z této tabulky použijeme k propojení zákazníků s jejich objednávkami později v modelu. Zákazníci samozřejmě nemusí být registrováni v našem modelu, aby mohli zadat objednávku, ale tento seznam stále potřebujeme. Registrovaným zákazníkům jsme mohli nabídnout slevy jako věrnostní program. Nebo bychom tyto údaje možná použili ke kontaktování zákazníků se speciálními nabídkami. Pro každého registrovaného zákazníka uložíme:

customer_name – Celé jméno zákazníka.
city_id – Odkazuje na city kde zákazník žije.
address – adresa zákazníka.
contact_phone – Telefonní číslo zákazníka.
email – E-mailová adresa, kterou zákazník použil během procesu registrace.
confirmation_code – Potvrzovací kód použitý během procesu registrace.
password – Heslo zvolené zákazníkem pro tuto aplikaci.
time_joined – Časové razítko, kdy se zákazník připojil k naší aplikaci.

Nabídky

Tato oblast obsahuje informace o jídelních lístcích našich restaurací. Prozatím předpokládejme, že všechny naše restaurace používají stejné menu.

První tabulka je category slovník. Obsahuje pouze jeden UNIKÁTNÍ atribut, category_name . Toto pole pravděpodobně obsahuje obvyklé kategorie nabídky, jako jsou „nápoje“, „předkrmy“, „saláty“, „sendviče“, „pizza“ atd.

Dále máme menu_item stůl. Uvádí všechny položky, které máme (nebo měli) v některém z našich menu. U každé položky uložíme:

item_name – Název této položky, např. „kuřecí sendvič“.
category_id – Odkazuje na category že věc patří, např. „sendviče“.
description – Popis této položky. Mělo by to být stejné jako na tištěné nabídce.
ingredients – Ingredience použité k výrobě této položky a jejich množství. Toto pole může ve skutečnosti ukládat recept.
price – Aktuální cena za jednu položku (např. jeden kuřecí sendvič).
active – Pokud je položka nabízena v aktuální nabídce.

Pokud chceme ukládat nabídky ve více jazycích, měli bychom použít přístup, jako je ten, který je uveden v tomto článku.

Většina restaurací má speciální časově omezené nabídky. Mohou mít také nějaké nabídky na neomezenou dobu. Využijeme offer stůl pro tyto. Pro každý z nich budeme mít:

date_active_from a date_active_to – Společně definují, kdy je tato nabídka aktivní. Pokud má nabídka neomezené trvání nebo pokud je založena na hodinách, nikoli dnech, budou tyto dva atributy obsahovat hodnoty NULL. Příkladem tohoto typu nabídky je „Kupte si během měsíce března jedno kari a získejte jedno s 50% slevou“.
time_active_from a time_active_to – Definuje denní dobu, kdy je nabídka platná – např. “Získejte zdarma kávu od 6 do 9 hodin každý den.”
offer_price – Cena za tuto nabídku.

Všechny položky menu zahrnuté v nabídkách jsou uloženy v in_offer stůl. Tato tabulka obsahuje UNIKÁTNÍ pár offer_id – menu_item_id .

Pokud mají naše restaurace různé jídelníčky, musíme vytvořit samostatné menu pro každou restauraci. Potom bychom museli propojit menu a nabídky s restauracemi pomocí cizích klíčů. To by nám umožnilo měnit menu a nabídky pro jakoukoli restauraci bez dopadu na ostatní. To by databázi jen nezkomplikovalo; obchodní model by se také stal složitějším. To je důvod, proč většina řetězců restaurací zůstává pouze u jednoho menu a proč jsem se rozhodl tuto metodu v tomto modelu nepoužít.

Objednávky

Poslední předmět v našem modelu je Orders předmětová oblast. Zde budeme mít vše potřebné k uložení objednávek a jejich stavů.

Centrální tabulka je zde placed_order stůl. Nejlepší je nepoužívat jako název této tabulky pouze „objednávka“:„objednávka“ je klíčové slovo SQL. Snažte se vyhnout používání klíčových slov jako názvů tabulek a sloupců; jinak se při psaní dotazů mohou objevit chyby. U každé objednávky zaznamenáme:

restaurant_id – ID restaurant související s touto objednávkou.
order_time – Časové razítko, kdy byla objednávka zadána.
estimated_delivery_time – Časové razítko plánovaného doručení této objednávky.
food_ready – Časové razítko označující, kdy byly položky objednávky připraveny. To bude obsahovat hodnotu NULL, dokud nebude jídlo připraveno. Tento atribut jsme mohli použít k výpočtu časového rozdílu mezi okamžikem zadání objednávky a přípravou jídla. Mohli bychom jej také použít ke zjištění, kolik času uplynulo mezi tím, kdy bylo jídlo hotové a kdy bylo doručeno. Tyto informace mohou být velmi užitečné pro zvýšení efektivity zaměstnanců.
actual_delivery_time – Časové razítko, kdy byla tato objednávka skutečně doručena. Dokud nebude jídlo doručeno zákazníkovi, bude NULL.
delivery_address – Adresa, kam má být objednávka doručena.
customer_id – ID customer kdo tu objednávku zadal. Tento atribut může obsahovat hodnotu NULL, pokud objednávku zadal někdo, kdo není registrovaným uživatelem aplikace.
price – Cena za všechny položky zahrnuté v této objednávce.
discount – Výše slevy (např. kupon nebo věrnostní sleva) použitá na cenu, pokud existuje.
final_price – Cena objednávky mínus sleva.
comment – Další komentáře vložené zákazníkem při zadání objednávky. Mohou to být další pokyny k doručení nebo cokoli jiného, co zákazník považuje za důležité.
ts – Časové razítko, kdy byl tento záznam vložen do tabulky.

in_order tabulka uvádí všechny položky nebo speciální nabídky, které jsou součástí objednávky. Pro každý záznam v této tabulce uložíme:

placed_order_id – ID související order .
offer_id – Odkazuje na offer tabulky, ale pouze pokud je v této objednávce zahrnuta jedna nebo více nabídek. V takovém případě menu_item_id atribut bude NULL.
menu_item_id – Odkazuje na menu_item tabulky, ale pouze pokud se tento záznam týká položky nabídky a nikoli nabídky.
quantity – Kolik nabídek nebo položek menu je zahrnuto v této objednávce.
item_price – Cena jedné nabídky nebo položky menu.
price – Celková cena za tento řádek vyjádřená jako item_price * quantity .
comment – Jakékoli komentáře vložené zákazníkem, které se týkají konkrétně dané položky objednávky, např. “Nakrájejte pizzu na 8 plátků.”

comment tabulka nám umožňuje podporovat vkládání více komentářů souvisejících s objednávkami. U každého komentáře uložíme ID související objednávky a ID zákazníka. Uložíme také časové razítko, kdy byl tento komentář vložen. Také označíme, zda tento komentář byl stížností nebo komplimentem; pouze jeden z těchto dvou může být nastaven najednou. Pokud nejsou nastaveny žádné, budeme tento komentář považovat za neutrální.

Poslední dvě tabulky v našem modelu souvisí se stavy, které přiřadíme objednávkám. status_catalog tabulka obsahuje seznam všech možných UNIKÁTNÍCH status_name atributy, které jsme mohli přiřadit objednávkám. order_status tabulka obsahuje všechny stavy, které jsou přiřazeny k objednávkám. Pro každý záznam v této tabulce uložíme cizí klíče související s objednávkou a stavem a časovým razítkem, kdy byl tento stav přiřazen.

Co si myslíte o datovém modelu rozvozu restaurací?

Dnes jsme diskutovali o datovém modelu, který lze použít k organizaci, správě a ukládání objednávek donášek restaurací. Můžeme sledovat stav každé objednávky a některé finanční detaily. Mám pár nápadů, jak bychom mohli udělat tento model robustnějším, ale rád bych slyšel váš názor. Sdílejte to prosím v sekci komentářů!