Модел на данни за доставка в ресторант

Гладни сте, но не искате да готвите? Обадете се в ресторант, поръчайте любимото си ястие и прочетете за модел на данни, който може да организира целия процес.

Въпреки изобилието от технологии за „спестяване на време“, изглежда, че имаме по-малко време за задоволяване на основни нужди – като хранене. Ако искаме да ядем нещо, но нямаме време (или умения) да го приготвим сами, можем да поръчаме храна от ресторант (т.е. за вкъщи или за вкъщи), което ще донесе храната ни точно до вратите ни. Разбира се, ние трябва да платим за това удобство, така че очакваме храната да е добра и топла!

Очевидно всеки ресторант е мотивиран да поддържа клиентите си доволни. Може да се изненадате да научите колко много работа се влага в провеждането на храна за вкъщи. Повечето използват някакъв вид система за проследяване за управление на поръчки и доставки. Нека да разгледаме модела на данни под една такава система. Вземете си лека закуска, седнете и се насладете на статията.

Какво трябва да знаем за ресторантьорския бизнес?

Приготвянето на храна и доставянето й на клиентите не е лесно. На първо място, трябва да имате талант и знания, за да приготвите вкусни ястия. Вие също трябва да сте организирани:всичко трябва да функционира перфектно, ако тези ястия ще бъдат доставени навреме и на правилното място!

Преди да започнем да доставяме храна, трябва да знаем:

• Кой е поръчал ястието
• Къде и кога трябва да се достави храната
• Какви ястия са включени в поръчката
• Какви съставки са ни необходими, за да изпълним поръчката
• Ако поръчката вече е платена

Също така трябва да проследяваме статусите на доставка и да записваме отзивите на клиентите за тяхното хранене и/или нашия процес на доставка. Освен това, може би искаме да знаем кои ястия са най-популярни (или най-малко). И ние също трябва да запазим известна финансова информация за целите на отчитането и анализа.

Да предположим, че имаме приложение, което нашите клиенти могат да използват, за да правят поръчки за доставка. Позволява им да избират елементи от менюто, да плащат за тях и да посочат време за доставка и адрес. Как може да изглежда моделът на данни под такова приложение?

Моделът на данните

Можете да отворите този модел във вашия браузър, като щракнете върху Edit model in your browser бутон.

Моделът на данни се състои от три предметни области:

• Restaurants & customers
• Menus
• Orders

Ще представим всяка тематична област в реда, в който е изброен.

Ресторанти и клиенти

Restaurants & customers Темата съдържа три таблици, които съхраняват подробности за нашите ресторанти (може да са повече от един), градовете, в които оперираме, и нашите клиенти.

Както клиентите, така и ресторантите се намират в градове (или населени места, села и т.н.). Следователно имаме нужда от city речник. Той съдържа само два атрибута, city_name и zip_code . Ако работим в повече от една държава, ще ни е необходим и речник за държави, който да е свързан с тази таблица, но няма да навлизаме в това тук.

След това се нуждаем от списък на всички ресторанти, които оперираме. Ще използваме restaurant маса за това. За да опростим нещата, ще съхраняваме само address на всеки ресторант и препратка към city където се намира.

Последната таблица в тази тематична област е customer маса. Тук ще съхраняваме списък на всички наши регистрирани клиенти за доставка. Ще използваме данни от тази таблица, за да свържем клиентите с техните поръчки по-късно в модела. Разбира се, клиентите не трябва да са регистрирани в нашия модел, за да направят поръчка, но ние все още се нуждаем от този списък. Бихме могли да предложим отстъпки на регистрирани клиенти като програма за лоялност. Или може би ще използваме тези данни, за да се свържем с клиенти със специални оферти. За всеки регистриран клиент ще съхраняваме:

• customer_name – Пълното име на клиента.
• city_id – Препраща city където живее клиентът.
• address – Адрес на клиента.
• contact_phone – Телефонен номер на клиента.
• email – Имейл адресът, използван от клиента по време на процеса на регистрация.
• confirmation_code – Код за потвърждение, използван по време на процеса на регистрация.
• password – Паролата, избрана от клиента за това приложение.
• time_joined – Печат за време, когато клиентът се е присъединил към нашето приложение.

Менюта

Тази тема съдържа информация за менютата на нашите ресторанти. Засега да приемем, че всички наши ресторанти използват едно и също меню.

Първата таблица е category речник. Той съдържа само един УНИКАЛЕН атрибут, category_name . Това поле вероятно ще съдържа обичайните категории от менюто, като „напитки“, „предястия“, „салати“, „сандвичи“, „пица“ и т.н.

След това имаме menu_item маса. Той изброява всички елементи, които имаме (или сме имали) в някое от нашите менюта. За всеки артикул ще съхраняваме:

• item_name – Име на този артикул, напр. „сандвич с пиле“.
• category_id – Препраща към category че артикулът принадлежи, напр. „сандвичи“.
• description – Описание на този артикул. Това трябва да е същото като в отпечатаното меню.
• ingredients – Съставките, използвани за производството на този артикул и техните количества. Това поле всъщност може да съхранява рецепта.
• price – Текущата цена за един артикул (напр. един сандвич с пиле).
• active – Ако елементът се предлага в текущото меню.

Ако искаме да съхраняваме менюта на няколко езика, трябва да използваме подход като този, представен в тази статия.

Повечето ресторанти имат специални, ограничени във времето оферти. Те могат също да имат някои оферти за неограничен период от време. Ще използваме offer маса за тези. За всеки от тях ще имаме:

• date_active_from и date_active_to – Заедно те определят кога тази оферта е активна. Ако офертата има неограничена продължителност или ако се основава на часове, а не на дни, тези два атрибута ще съдържат стойности NULL. Пример за този тип оферта е „През месец март купете едно къри и вземете едно 50% отстъпка“.
• time_active_from и time_active_to – Определя времето от деня, в което офертата е валидна – напр. „Вземете безплатно кафе от 6 до 9 сутринта всеки ден.“
• offer_price – Цената за тази оферта.

Всички елементи от менюто, включени в офертите, се съхраняват в in_offer маса. Тази таблица съдържа УНИКАЛНАТА двойка offer_id – menu_item_id .

Ако нашите ресторанти имат различни менюта, трябва да създадем отделно меню за всеки ресторант. След това ще трябва да свържем менюта и оферти с ресторанти, използващи чужди ключове. Това ще ни позволи да променяме менютата и офертите за всеки ресторант, без да засягаме останалите. Това не само би усложнило базата данни; бизнес моделът също ще стане по-сложен. Ето защо повечето вериги ресторанти се придържат само към едно меню и реших да не използвам този метод в този модел.

Поръчки

Последната тематична област в нашия модел е Orders предметна област. Тук ще разполагаме с всичко необходимо за съхраняване на поръчките и техните състояния.

Централната таблица тук е placed_order маса. Най-добре е да не използвате само „поръчка“ като име на тази таблица:„поръчка“ е ключова дума на SQL. Опитайте се да избягвате използването на ключови думи като имена за таблици и колони; в противен случай може да получите грешки при писане на заявки. За всяка поръчка ще записваме:

• restaurant_id – ИД на restaurant свързани с тази поръчка.
• order_time – Отпечатък за дата на поръчката.
• estimated_delivery_time – Времева марка на планираната доставка на тази поръчка.
• food_ready – Печат за време, обозначаващ кога артикулите на поръчката са били подготвени. Това ще съдържа стойност NULL, докато храната не бъде приготвена. Можем да използваме този атрибут, за да изчислим разликата във времето между момента на подаване на поръчката и приготвянето на храната. Бихме могли също да го използваме, за да открием колко време е минало между кога храната е била готова и когато е била доставена. Тази информация може да бъде много полезна за повишаване на ефективността на персонала.
• actual_delivery_time – Времева марка за това кога тази поръчка е била действително доставена. Ще бъде NULL, докато храната не бъде доставена на клиента.
• delivery_address – Адресът, на който трябва да бъде доставена поръчката.
• customer_id – ИД на customer който е направил тази поръчка. Този атрибут може да съдържа стойност NULL, ако поръчката е направена от някой, който не е регистриран потребител на приложението.
• price – Цената за всички артикули, включени в тази поръчка.
• discount – Размерът на отстъпката (напр. купон или отстъпка за лоялност), приложен към цената, ако има такава.
• final_price – Цената на поръчката минус отстъпката.
• comment – Допълнителни коментари, въведени от клиента при направена поръчка. Това може да са допълнителни инструкции за доставка или нещо друго, което клиентът намира за важно.
• ts – Отпечатък за време, когато този запис е бил вмъкнат в таблицата.

in_order таблицата изброява всички артикули или специални оферти, които са включени в поръчка. За всеки запис в тази таблица ще съхраняваме:

• placed_order_id – ИД на свързаната order .
• offer_id – Препраща към offer таблица, но само когато една или повече оферти са включени в този ред. В този случай menu_item_id атрибутът ще бъде NULL.
• menu_item_id – Препраща menu_item таблица, но само ако този запис е свързан с елемент от менюто, а не с оферта.
• quantity – Колко оферти или елементи от менюто са включени в тази поръчка.
• item_price – Цената на една оферта или елемент от менюто.
• price – Общата цена за този ред, изразена като item_price * quantity .
• comment – Всички коментари, въведени от клиента, които се отнасят конкретно до този артикул на поръчка, напр. „Моля, нарежете пицата на 8 филийки.

comment таблица ни позволява да поддържаме вмъкването на множество коментари, свързани с поръчки. За всеки коментар ще съхраняваме идентификатора на съответната поръчка и идентификатора на клиента. Ще съхраним и времева марка за това кога е въведен този коментар. Ще отбележим също дали този коментар е оплакване или комплимент; само един от тези две може да бъде зададен едновременно. Ако не е зададен нито един, тогава ще третираме този коментар като неутрален.

Последните две таблици в нашия модел са свързани със статуси, които ще присвоим на поръчките. status_catalog таблицата съдържа списък с всички възможни УНИКАЛНИ status_name атрибути, които можем да присвоим на поръчки. order_status таблицата съдържа всички състояния, които са присвоени на поръчките. За всеки запис в тази таблица ще съхраняваме външни ключове, свързани с поръчката и състоянието, както и времевия печат, когато този статус е бил присвоен.

Какво мислите за модела на данни за доставка в ресторант?

Днес обсъдихме модел на данни, който може да се използва за организиране, управление и съхранение на поръчки за доставка в ресторант. Можем да проследим статуса на всяка поръчка и някои от финансовите подробности. Имам няколко идеи как можем да направим този модел по-здрав, но ще се радвам да чуя вашето мнение. Моля, споделете го в секцията за коментари!