Pokud existuje způsob, jak si objednat potraviny online, proč jej nevyužít? Tento článek zkoumá datový model za doručovacím systémem obchodu s potravinami.
Stále máme zvláštní pocit, když si něco natrháme ze zahrady a hned to připravíme – ale není to něco, co můžeme dělat často. Dnešní rychlé tempo to neumožňuje. Ve skutečnosti nám někdy ani nedovolí jít si do obchodu „vybrat“ potraviny. Má tedy smysl ušetřit si čas a pomocí aplikace si objednat, co potřebujeme. Naše objednávka se teprve objeví u nás doma. Možná nezískáme ten zvláštní pocit čerství, ale jídlo na našem stole bude.
Datový model za takovou aplikací je tématem dnešního článku.
Co potřebujeme pro datový model dodávky potravin?
Myšlenka tohoto modelu spočívá v tom, že aplikace (webová, mobilní nebo obojí) umožní registrovaným zákazníkům vytvořit objednávku (složenou z produktů z našeho obchodu). Poté bude tato objednávka doručena zákazníkovi. Samozřejmě budeme uchovávat zákaznická data a seznam všech dostupných produktů, abychom to podpořili.
Zákazníci mohou zadat více objednávek, které obsahují různé položky v různých množstvích. Když je objednávka zákazníka přijata, zaměstnanci obchodu by měli být informováni, aby mohli najít a zabalit potřebné položky. (To může vyžadovat jeden nebo více kontejnerů.) Nakonec budou kontejnery dodány, buď společně, nebo odděleně.
V samotné aplikaci by zákazníci a zaměstnanci měli mít možnost vkládat poznámky a hodnotit druhou stranu po doručení.
Datový model
Datový model se skládá ze tří tematických oblastí:
Items & unitsCustomers & employeesOrders
Každou oblast představíme v pořadí, v jakém je uvedena.
Část 1:Předměty a jednotky
Začneme Items & units předmětová oblast. Přestože je to malá část našeho modelu, obsahuje dvě velmi důležité tabulky.
unit tabulka ukládá informace o jednotkách, které přiřadíme k libovolné položce v našem inventáři. Pro každou hodnotu v této tabulce uložíme dvě UNIKÁTNÍ hodnoty:unit_name (např. „kilogram“) a unit_short (např. „kg“). Všimněte si, že unit_short je zkratka pro unit_name .
Druhá tabulka v této oblasti je item . Uvádí všechny položky, které máme v inventáři. U každé položky uložíme:
item_name– UNIKÁTNÍ název, který pro danou položku použijeme.price– Aktuální cena této položky.item_photo– Odkaz na fotografii této položky.description– Dodatečný textový popis položky.unit_id– Odkazuje naunitslovník a označuje jednotku použitou k měření dané položky.
Vezměte prosím na vědomí, že jsem zde vynechal několik věcí. Nejdůležitější je příznak, který označuje, zda je skladová položka aktuálně nabízena k prodeji. proč to nemáme? Vyžadovalo by to alespoň jedno další pole (příznak) a také další tabulku (k uložení historických změn pro každou položku). Abychom to zjednodušili, předpokládal jsem, že všechny položky, které máme na skladě, lze také prodat.
Druhou důležitou věcí, kterou jsem vynechal, je sledování stavu skladu. Můj předpoklad je, že vše odesíláme z jednoho centrálního skladu a že budeme mít vždy dostupné zboží. Pokud nějakou položku nemáme, jednoduše upozorníme zákazníka a nabídneme mu náhradu za podobnou.
Část 2:Zákazníci a zaměstnanci
Customers & employees předmětová oblast obsahuje všechny tabulky potřebné k uložení dat zákazníků a zaměstnanců. Tyto informace použijeme v centrální části našeho modelu.
employee tabulka obsahuje seznam všech příslušných zaměstnanců (např. baliči potravin a doručovatelů). U každého zaměstnance uložíme jeho first_name a last_name a UNIKÁTNÍ employee_code hodnota. Přestože je sloupec id také UNIKÁTNÍ (a primární klíč této tabulky), je lepší použít jako identifikátor zaměstnance jinou reálnou hodnotu (např. DIČ). Máme tedy employee_code pole.
Všimněte si, že jsem nezahrnul přihlašovací údaje zaměstnanců, role zaměstnanců a způsob sledování historie rolí. Ty lze snadno přidat, jak je popsáno v tomto článku.
Nyní do našeho modelu přidáme zákazníky. To bude vyžadovat další dvě tabulky.
Zákazníci budou geograficky segmentováni, takže budeme potřebovat city slovník. Pro každé město, kde nabízíme rozvoz potravin, uložíme city_name a postal_code . Společně tvoří alternativní klíč této tabulky.
Zákazníci jsou rozhodně nejdůležitější součástí tohoto modelu; jsou to oni, kdo celý proces iniciuje. Kompletní seznam našich zákazníků uložíme do customer stůl. Pro každého zákazníka uložíme následující:
first_name– Křestní jméno zákazníka.last_name– Příjmení zákazníka.user_name– Uživatelské jméno, které si zákazník zvolil při nastavování svého účtu.password– Heslo, které si zákazník zvolil při nastavování svého účtu.time_inserted– Okamžik, kdy byl tento záznam vložen do databáze.confirmation_code– Kód, který byl vygenerován během registračního kódu. Tento kód bude použit k ověření jejich e-mailové adresy.time_confirmed– Když došlo k potvrzení e-mailem.contact_email– E-mailová adresa zákazníka, která se také používá jako potvrzovací e-mail.contact_phone– Telefonní číslo zákazníka.city_id– IDcitykde má zákazník bydliště.address– adresa bydliště zákazníka.delivery_city_id– IDcitykam má být objednávka zákazníka doručena.delivery_address– Preferovaná doručovací adresa. Upozorňujeme, že tato adresa může být (ale nemusí) stejná jako adresa domova zákazníka.
Část 3:Objednávky
Ústřední a nejdůležitější částí tohoto modelu jsou Orders předmětová oblast. Zde najdeme všechny tabulky potřebné k zadání objednávky a sledování položek, dokud nebudou doručeny zákazníkům.
Celý proces začíná, když zákazník zadá objednávku. Seznam všech zadaných objednávek je v placed_order stůl. Záměrně jsem použil tento název a ne „objednávka“, protože objednávka je vyhrazené klíčové slovo SQL. U každé objednávky uložíme:
customer_id– IDcustomerkterá zadala tuto objednávku.time_placed– Časové razítko, kdy byla tato objednávka zadána.details– Všechny podrobnosti týkající se této objednávky v nestrukturovaném textovém formátu.delivery_city_id– Odkaz nacitykam má být tato objednávka doručena.delivery_address– Adresa, na kterou má být tato objednávka doručena.grade_customer&grade_employee– Známky dané zaměstnancem a zákazníkem po dokončení objednávky. Do té chvíle tento atribut obsahuje hodnotu NULL. Hodnocení zákazníka ukazuje, jak byl s našimi službami spokojený; známka zaměstnance nám poskytuje informace o tom, co můžeme očekávat, až zákazník příště zadá objednávku.
Během procesu zadávání objednávky si zákazník vybere jednu nebo více položek. Pro každou položku definují požadované množství. Seznam všech položek souvisejících s každou objednávkou je uložen v order_item stůl. Pro každý záznam v této tabulce uložíme ID související objednávky (placed_order_id ), položka (item_id ), požadované množství a price kdy byla zadána tato objednávka.
Kromě toho, co chtějí doručit, zákazníci také definují požadovaný čas doručení . Pro každou objednávku vytvoříme jeden záznam v delivery stůl. Tím se zaznamená delivery_time_planned a vložit další textové poznámky. placed_order_id atribut bude také definován při vložení tohoto záznamu. Zbývající dva atributy budou definovány, když dané doručení přiřadíme zaměstnanci (employee_id ) a kdy byla objednávka doručena (delivery_time_actual ).
I když to může vypadat, že budeme mít pouze jednu dodávku na objednávku, nemusí to tak být vždy. Možná budeme muset provést dvě nebo více dodávek na objednávku, a to je hlavní důvod, proč jsem se rozhodl vložit data o doručení do nové tabulky.
Když začneme zpracovávat objednávku, zaměstnanci zabalí položky do jedné nebo více krabic. Každý box bude JEDINEČNĚ definován svým box_code a bude přiřazen k dodávce (delivery_id ). Uložíme také ID zaměstnance, který krabici připravil.
Každá krabice bude obsahovat jednu nebo více položek. Proto v item_in_box tabulky, budeme muset uložit odkazy na box tabulka (box_id ) a item tabulka (item_id ), jakož i množství umístěné v této krabici. Poslední atribut, is_replacement , označuje, zda je položka náhradou za jinou položku. Můžeme očekávat, že zaměstnanec bude kontaktovat zákazníka před vložením náhradní položky do krabice. Jedním z výsledků této akce by mohlo být, že zákazník souhlasí s náhradní položkou; dalším může být zrušení celé objednávky.
Zbývající tři tabulky v modelu úzce souvisí se stavy a komentáři.
Nejprve uložíme všechny možné stavy do status_catalog . Každý stav je JEDINEČNĚ definován svým status_name . Můžeme očekávat stavy jako „objednávka vytvořena“, „objednávka zadána“, „položky zabalené“, „na cestě“ a „doručeno“.
Stavy budou objednávkám přidělovány buď automaticky (po dokončení některých částí procesu), nebo v některých případech ručně (např. pokud dojde k problému s objednávkou). Všechny dostupné stavy objednávek jsou uloženy v order_status stůl. Kromě cizích klíčů ze dvou tabulek (status_catalog a placed_order ), uložíme skutečné časové razítko, kdy byl tento stav přiřazen (status_time ) a jakékoli další details v textovém formátu.
Poslední tabulkou v tomto modelu jsou notes stůl. Smyslem této tabulky je vložit všechny další komentáře související s danou objednávkou (placed_order_id ). Komentáře mohou vkládat zaměstnanci nebo zákazníci. Pro každý záznam pouze jeden z employee_id nebo customer_id pole budou obsahovat hodnotu; druhý bude NULL. Uložíme okamžik, kdy byla tato poznámka vložena do systému (note_time ) a note_text .
Jaké změny byste provedli v datovém modelu dodávky potravin?
Dnes jsme diskutovali o datovém modelu, který by mohl podporovat webové a mobilní aplikace pro doručování potravin – jak z pohledu zákazníka, tak z pohledu zaměstnance. Jak již bylo zmíněno v tomto článku, existuje mnoho způsobů, jak tento model vylepšit. Neváhejte a přidejte své návrhy. Řekněte nám, co byste k tomuto modelu přidali nebo z něj odstranili. Nebo byste možná tuto strukturu organizovali úplně jinak. Dejte nám vědět v sekci komentářů!