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

Ако има начин да поръчате хранителни стоки онлайн, защо да не го използвате? Тази статия разглежда модела на данни зад системата за доставка на хранителни магазини.

Все още изпитваме специално усещане, когато берем нещо от градината и след това го приготвяме веднага – но това не е нещо, което можем да правим често. Днешното бързо темпо не го позволява. Всъщност понякога дори не ни позволява да отидем до магазина, за да „изберем“ нашите хранителни стоки. Така че има смисъл да си спестим малко време и да използваме приложение, за да поръчаме това, от което се нуждаем. Нашата поръчка просто ще се появи в дома ни. Може би няма да получим това специално прясно подбрано усещане, но на масата ни ще има храна.

Моделът на данни зад такова приложение е темата на днешната статия.

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

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

Клиентите могат да направят множество поръчки, които включват различни артикули в различни количества. Когато поръчката на клиента бъде получена, служителите на магазина трябва да бъдат уведомени, за да могат да намерят и опаковат необходимите артикули. (Това може да изисква един или повече контейнери.) И накрая, контейнерите ще бъдат доставени заедно или поотделно.

В самото приложение клиентите и служителите трябва да могат да вмъкват бележки и да оценяват другата страна след извършване на доставката.

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

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

• Items & units
• Customers & employees
• Orders

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

Раздел 1:Елементи и единици

Ще започнем с Items & units предметна област. Въпреки че е малка част от нашия модел, той съдържа две много важни таблици.

unit таблицата съхранява информация за единиците, които ще присвоим на всеки артикул в нашия инвентар. За всяка стойност в тази таблица ще съхраняваме две УНИКАЛНИ стойности:unit_name (напр. „килограм“) и unit_short (напр. „kg“). Забележете, че unit_short е съкращението за unit_name .

Втората таблица в тази тематична област е item . Той изброява всички артикули, които имаме в инвентара. За всеки артикул ще съхраняваме:

• item_name – УНИКАЛНОТО име, което ще използваме за този артикул.
• price – Текущата цена на този артикул.
• item_photo – Връзка към снимка на този артикул.
• description – Допълнително текстово описание на артикула.
• unit_id – Препраща към unit речник и обозначава единицата, използвана за измерване на този елемент.

Моля, имайте предвид, че пропуснах няколко неща тук. Най-важният от тях е флаг, който обозначава дали даден артикул от инвентара в момента се предлага за продажба. Защо нямаме това? Това ще изисква поне едно допълнително поле (флаг), както и друга таблица (за съхраняване на исторически промени за всеки елемент). За да опростя нещата, предположих, че всички артикули, които имаме в инвентара, също са налични за продажба.

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

Раздел 2:Клиенти и служители

Customers & employees Темата съдържа всички таблици, необходими за съхраняване на данни за клиенти и служители. Ще използваме тази информация в централната част на нашия модел.

employee таблицата съдържа списък на всички съответни служители (например опаковачи на хранителни стоки и хора за доставка). За всеки служител ще съхраняваме неговото first_name и last_name и УНИКАЛЕН employee_code стойност. Въпреки че колоната с идентификатор също е УНИКАЛНА (и първичният ключ на тази таблица), по-добре е да използвате друга, реална стойност (например номер по ДДС) като идентификатор на служител. Така имаме employee_code поле.

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

Сега ще добавим клиенти към нашия модел. Това ще отнеме още две маси.

Клиентите ще бъдат сегментирани географски, така че ще ни трябва city речник. За всеки град, в който предлагаме доставка на хранителни стоки, ще съхраняваме city_name и postal_code . Заедно те образуват алтернативния ключ на тази таблица.

Клиентите определено са най-важната част от този модел; те са тези, които инициират целия процес. Ще съхраняваме пълен списък на нашите клиенти в customer маса. За всеки клиент ще съхраняваме следното:

• first_name – Първото име на клиента.
• last_name – Фамилията на клиента.
• user_name – Потребителското име, което клиентът е избрал при настройването на акаунта си.
• password – Паролата, която клиентът е избрал при настройването на акаунта си.
• time_inserted – Моментът, в който този запис е бил вмъкнат в базата данни.
• confirmation_code – Код, генериран по време на регистрационния код. Този код ще се използва за потвърждаване на имейл адреса им.
• time_confirmed – Когато се получи потвърждение по имейл.
• contact_email – Имейл адресът на клиента, който се използва и като имейл за потвърждение.
• contact_phone – Телефонен номер на клиента.
• city_id – ИД на city където клиентът пребивава.
• address – Домашен адрес на клиента.
• delivery_city_id – ИД на city където трябва да бъде доставена поръчката на клиента.
• delivery_address – Предпочитан адрес за доставка. Имайте предвид, че това може да бъде (но не е задължително) същото като домашния адрес на клиента.

Раздел 3:Поръчки

Централната и най-важна част от този модел са Orders предметна област. Тук ще намерим всички таблици, необходими за извършване на поръчка и проследяване на артикули, докато бъдат доставени на клиентите.

Целият процес започва, когато клиент направи поръчка. Списък с всяка поръчка, правена някога, е в placed_order маса. Умишлено използвах това име, а не „поръчка“, защото поръчката е ключова дума, запазена в SQL. За всяка поръчка ще съхраняваме:

• customer_id – ИД на customer който направи тази поръчка.
• time_placed – Печатът за дата, когато тази поръчка е направена.
• details – Всички подробности, свързани с тази поръчка, в неструктуриран текстов формат.
• delivery_city_id – Препратка към city където тази поръчка трябва да бъде доставена.
• delivery_address – Адресът, на който трябва да бъде доставена тази поръчка.
• grade_customer &grade_employee – Оценки, дадени от служителя и клиента след приключване на поръчката. До този момент този атрибут съдържа стойност NULL. Оценката на клиента показва колко доволни са от нашата услуга; оценката на служител ни дава информация какво да очакваме следващия път, когато клиентът направи поръчка.

По време на процеса на подаване на поръчка клиентът ще избере един или повече артикула. За всеки артикул те ще определят желаното количество. Списък с всички артикули, свързани с всяка поръчка, се съхранява в order_item маса. За всеки запис в тази таблица ще съхраняваме идентификатори за свързаната поръчка (placed_order_id ), елемент (item_id ), желаното количество и price когато тази поръчка е направена.

В допълнение към какво те искат да бъдат доставени, клиентите също така ще определят желаното от тях време за доставка . За всяка поръчка ще създадем един запис в delivery маса. Това ще запише delivery_time_planned и вмъкнете допълнителни текстови бележки. placed_order_id атрибутът също ще бъде дефиниран, когато този запис бъде вмъкнат. Останалите два атрибута ще бъдат дефинирани, когато присвоим тази доставка на служител (employee_id ) и кога е доставена поръчката (delivery_time_actual ).

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

Когато започнем да обработваме поръчка, служителите ще опаковат артикулите в една или повече кутии. Всяка box ще бъде дефиниран УНИКАЛНО от своя box_code и ще бъде присвоен на доставка (delivery_id ). Ще съхраняваме и идентификационния номер на служителя, който е подготвил тази кутия.

Всяка кутия ще съдържа един или повече елементи. Следователно в item_in_box таблица, ще трябва да съхраняваме препратки към box таблица (box_id ) и item таблица (item_id ), както и количеството, поставено в тази кутия. Последният атрибут, is_replacement , обозначава дали даден артикул е заместител на друг елемент. Можем да очакваме, че служител ще се свърже с клиент, преди да постави резервен артикул в кутия. Един резултат от това действие може да бъде, че клиентът е съгласен със заместващия артикул; друго може да е анулирането на цялата поръчка.

Останалите три таблици в модела са тясно свързани със статуси и коментари.

Първо, ще съхраняваме всички възможни състояния в status_catalog . Всяко състояние е УНИКАЛНО дефинирано от неговото status_name . Можем да очакваме състояния като „поръчка е създадена“, „поръчана е“, „артикулите са опаковани“, „в транспорт“ и „доставено“.

Статусите ще бъдат присвоени на поръчките или автоматично (след приключване на някои части от процеса), или в някои случаи ръчно (например, ако има проблем с поръчката). Всички налични състояния на поръчките се съхраняват в order_status маса. Освен външни ключове от две таблици (status_catalog и placed_order ), ще съхраняваме действителната дата за време, когато това състояние е било присвоено (status_time ) и всякакви допълнителни details в текстов формат.

Финалната таблица в този модел са notes маса. Идеята зад тази таблица е да се вмъкнат всички допълнителни коментари, свързани с дадена поръчка (placed_order_id ). Коментарите могат да се добавят от служители или клиенти. За всеки запис само един от employee_id или customer_id полетата ще съдържат стойност; другият ще бъде NULL. Ще съхраним момента, когато тази бележка е била вмъкната в системата (note_time ) и note_text .

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

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