Está com fome, mas não quer cozinhar? Ligue para um restaurante, peça sua refeição favorita e leia sobre um modelo de dados que pode organizar todo o processo.
Apesar da abundância de tecnologia de “economia de tempo”, parece que temos menos tempo para atender às necessidades básicas – como comer. Se queremos comer algo, mas não temos tempo (ou habilidades) para cozinhar nós mesmos, podemos pedir comida em um restaurante (ou seja, para viagem ou para viagem), que trará nossas refeições diretamente à nossa porta. Claro que temos que pagar por essa comodidade, por isso esperamos que a comida seja boa e gostosa!
Obviamente, qualquer restaurante é motivado a manter seus clientes satisfeitos. Você pode se surpreender ao saber quanto trabalho é necessário para executar um takeaway. A maioria usa algum tipo de sistema de rastreamento para gerenciar pedidos e entregas. Vejamos o modelo de dados sob um desses sistemas. Pegue um lanche, sente-se e aproveite o artigo.
O que devemos saber sobre o negócio de restaurantes?
Fazer comida e entregá-la aos clientes não é fácil. Antes de tudo, é preciso ter talento e conhecimento para preparar refeições deliciosas. Você também precisa ser organizado:tudo precisa funcionar perfeitamente para que essas refeições sejam entregues na hora e no lugar certo!
Antes de começarmos a entregar qualquer refeição, precisamos saber:
- Quem pediu a refeição
- Onde e quando a refeição deve ser entregue
- Quais pratos estão incluídos no pedido
- Quais ingredientes precisamos para atender o pedido
- Se o pedido já foi pago
Também precisamos rastrear o status da entrega e registrar o feedback do cliente sobre sua refeição e/ou nosso processo de entrega. Além disso, talvez queiramos saber quais refeições são as mais (ou menos) populares. E também devemos manter algumas informações financeiras para fins de relatório e análise.
Vamos supor que temos um aplicativo que nossos clientes podem usar para fazer pedidos para entrega. Ele permite que eles escolham itens do menu, paguem por eles e especifiquem um horário e endereço de entrega. Como pode ser o modelo de dados sob esse aplicativo?
O modelo de dados
Você pode abrir este modelo em seu navegador clicando em
Edit model in your browser botão. O modelo de dados consiste em três áreas de assunto:
Restaurants & customersMenusOrders
Apresentaremos cada área de assunto na ordem em que está listada.
Restaurantes e clientes
Os Restaurants & customers A área de assunto contém três tabelas que armazenam detalhes sobre nossos restaurantes (pode haver mais de um), as cidades onde atuamos e nossos clientes.
Tanto os clientes como os restaurantes estão localizados nas cidades (ou vilas, aldeias, etc.). Portanto, precisamos de uma city dicionário. Ele contém apenas dois atributos, city_name e zip_code . Se atuássemos em mais de um país, também precisaríamos de um dicionário de países que estivesse relacionado a esta tabela, mas não entraremos nisso aqui.
Em seguida, precisamos de uma lista de todos os restaurantes que operamos. Usaremos o restaurant mesa para isso. Para simplificar, armazenaremos apenas o address de cada restaurante e uma referência à city Onde ele é localizado.
A última tabela nesta área de assunto é o customer tabela. É aqui que armazenaremos uma lista de todos os nossos clientes de entrega registrados. Usaremos os dados desta tabela para vincular os clientes a seus pedidos posteriormente no modelo. Obviamente, os clientes não precisam estar registrados em nosso modelo para fazer um pedido, mas ainda precisamos dessa lista. Poderíamos oferecer descontos para clientes cadastrados como um programa de fidelidade. Ou talvez usemos esses dados para entrar em contato com clientes com ofertas especiais. Para cada cliente registrado, armazenaremos:
customer_name– O nome completo do cliente.city_id– Faz referência àcityonde o cliente mora.address– O endereço do cliente.contact_phone– O número de telefone do cliente.email– O endereço de e-mail que o cliente usou durante o processo de registro.confirmation_code– Um código de confirmação usado durante o processo de registro.password– A senha selecionada pelo cliente para este aplicativo.time_joined– Um carimbo de data/hora de quando o cliente ingressou em nosso aplicativo.
Menus
Esta área de assunto contém informações sobre os menus dos nossos restaurantes. Por enquanto, vamos supor que todos os nossos restaurantes usem o mesmo cardápio.
A primeira tabela é a category dicionário. Ele contém apenas um atributo ÚNICO, category_name . Este campo provavelmente conterá as categorias usuais do menu, como “bebidas”, “entradas”, “saladas”, “sanduíches”, “pizza”, etc.
Em seguida, temos o menu_item tabela. Ele lista todos os itens que temos (ou tivemos) em qualquer um de nossos menus. Para cada item, armazenaremos:
item_name– Um nome para esse item, por exemplo. “sanduíche de frango”.category_id– Faz referência àcategoryque o item pertence, por exemplo. "sanduíches".description– Uma descrição desse item. Deve ser igual ao menu impresso.ingredients– Os ingredientes usados para produzir esse item e suas quantidades. Este campo pode armazenar uma receita.price– O preço atual de um item (por exemplo, um sanduíche de frango).active– Se o item for oferecido no menu atual.
Se quisermos armazenar menus em vários idiomas, devemos usar uma abordagem como a apresentada neste artigo.
A maioria dos restaurantes tem ofertas especiais por tempo limitado. Eles também podem ter algumas ofertas por um período ilimitado de tempo. Usaremos a
offer mesa para estes. Para cada um, teremos:date_active_fromedate_active_to– Juntos, eles definem quando esta oferta está ativa. Se uma oferta tiver duração ilimitada ou se for baseada em horas em vez de dias, esses dois atributos conterão valores NULL. Um exemplo desse tipo de oferta é “Durante o mês de março, compre um curry e ganhe um com 50% de desconto”.time_active_frometime_active_to– Define a hora do dia em que uma oferta é válida – ex. “Ganhe um café grátis das 6h às 9h todos os dias”.offer_price– O preço dessa oferta.
Todos os itens de menu incluídos nas ofertas são armazenados em
in_offer tabela. Esta tabela contém o par ÚNICO de offer_id – menu_item_id . Se nossos restaurantes tiverem cardápios diferentes, precisamos criar um cardápio separado para cada restaurante. Precisaríamos então relacionar menus e ofertas com restaurantes usando chaves estrangeiras. Isso nos permitiria alterar menus e ofertas para qualquer restaurante sem afetar os outros. Isso não apenas complicaria o banco de dados; o modelo de negócios também se tornaria mais complexo. É por isso que a maioria das redes de restaurantes fica com apenas um menu e por isso decidi não usar esse método neste modelo.
Pedidos
A última área de assunto em nosso modelo é o Orders área de estudo. É aqui que teremos tudo o que é necessário para armazenar pedidos e seus status.
A tabela central aqui é o placed_order tabela. É melhor não usar apenas “order” como o nome desta tabela:“order” é uma palavra-chave SQL. Tente evitar usar palavras-chave como nomes para tabelas e colunas; caso contrário, você poderá obter erros ao escrever consultas. Para cada pedido, vamos registrar:
restaurant_id– O ID dorestaurantrelacionado a esse pedido.order_time– Um carimbo de data/hora de quando o pedido foi feito.estimated_delivery_time– Um carimbo de data/hora da entrega planejada deste pedido.food_ready– Um carimbo de data/hora indicando quando os itens do pedido foram preparados. Este conterá um valor NULL até que a comida seja preparada. Poderíamos usar esse atributo para calcular a diferença de tempo entre o momento em que o pedido foi feito e o momento em que o alimento foi preparado. Também poderíamos usá-lo para descobrir quanto tempo decorreu entre quando a comida estava pronta e quando foi entregue. Essas informações podem ser muito úteis para aumentar a eficiência da equipe.actual_delivery_time– Um carimbo de data/hora de quando este pedido foi realmente entregue. Será NULL até que a comida seja entregue ao cliente.delivery_address– O endereço onde o pedido deve ser entregue.customer_id– O ID docustomerquem fez esse pedido. Esse atributo pode conter um valor NULL se o pedido tiver sido feito por alguém que não seja um usuário registrado do aplicativo.price– O preço de todos os itens incluídos nesse pedido.discount– O valor do desconto (por exemplo, cupom ou desconto de fidelidade) aplicado ao preço, se houver.final_price– O preço do pedido menos o desconto.comment– Comentários adicionais inseridos pelo cliente quando o pedido foi feito. Podem ser instruções de entrega adicionais ou qualquer outra coisa que o cliente considere importante.ts– Um carimbo de data/hora de quando este registro foi inserido na tabela.
O
in_order tabela lista todos os itens ou ofertas especiais que estão incluídos em um pedido. Para cada registro nesta tabela, armazenaremos:placed_order_id– O ID doorder.offer_id– Faz referência àoffertabela, mas apenas quando uma ou mais ofertas estão incluídas neste pedido. Nesse caso, omenu_item_idatributo será NULL.menu_item_id– Faz referência aomenu_itemtabela, mas somente se este registro estiver relacionado a um item de menu e não a uma oferta.quantity– Quantas ofertas ou itens de menu estão incluídos neste pedido.item_price– O preço de uma única oferta ou item de menu.price– O preço total para esta linha, expresso comoitem_price*quantity.comment– Quaisquer comentários inseridos pelo cliente relacionados especificamente a esse item do pedido, por exemplo, “Por favor, corte a pizza em 8 fatias”.
O
comment table nos permite suportar a inserção de vários comentários relacionados a pedidos. Para cada comentário, armazenaremos o ID do pedido relacionado e o ID do cliente. Também armazenaremos um carimbo de data/hora de quando este comentário foi inserido. Também marcaremos se este comentário foi uma reclamação ou um elogio; apenas um destes dois pode ser definido de cada vez. Se nenhum estiver definido, trataremos este comentário como neutro. As duas últimas tabelas em nosso modelo estão relacionadas aos status que atribuiremos aos pedidos. O
status_catalog tabela contém uma lista de todos os possíveis status_name UNIQUE atributos que poderíamos atribuir aos pedidos. O order_status A tabela contém todos os status atribuídos aos pedidos. Para cada registro nesta tabela, armazenaremos chaves estrangeiras relacionadas ao pedido e status e o carimbo de data/hora em que esse status foi atribuído. O que você acha do modelo de dados de entrega do restaurante?
Hoje discutimos um modelo de dados que pode ser usado para organizar, gerenciar e armazenar pedidos de entrega de restaurantes. Podemos acompanhar o status de cada pedido e alguns dos detalhes financeiros. Tenho algumas ideias sobre como poderíamos tornar este modelo mais robusto, mas ficaria feliz em ouvir sua opinião. Por favor, compartilhe-o na seção de comentários!
