¿Tienes hambre pero no quieres cocinar? Llama a un restaurante, pide tu comida favorita y lee sobre un modelo de datos que puede organizar todo el proceso.
A pesar de la abundancia de tecnología que “ahorra tiempo”, parece que tenemos menos tiempo para satisfacer las necesidades básicas, como comer. Si queremos comer algo pero no tenemos el tiempo (o las habilidades) para cocinarlo nosotros mismos, podemos pedir comida en un restaurante (es decir, para llevar o comida para llevar), que traerá nuestras comidas directamente a nuestras puertas. Por supuesto, tenemos que pagar por esta comodidad, ¡así que esperamos que la comida sea buena y caliente!
Obviamente, cualquier restaurante está motivado para mantener satisfechos a sus clientes. Es posible que se sorprenda al saber cuánto trabajo se necesita para administrar una comida para llevar. La mayoría utiliza algún tipo de sistema de seguimiento para gestionar pedidos y entregas. Veamos el modelo de datos debajo de uno de esos sistemas. Tómese un refrigerio, siéntese y disfrute del artículo.
¿Qué debemos saber sobre el negocio de los restaurantes?
Hacer comida y entregarla a los clientes no es fácil. En primer lugar, debe tener talento y conocimiento para preparar comidas deliciosas. También debe organizarse:¡todo debe funcionar perfectamente si estas comidas se van a entregar a tiempo y en el lugar correcto!
Antes de comenzar a entregar comidas, necesitamos saber:
- Quién ordenó la comida
- Dónde y cuándo se debe entregar la comida
- Qué platos están incluidos en el pedido
- Qué ingredientes necesitamos para cumplir con el pedido
- Si el pedido ya ha sido pagado
También necesitamos realizar un seguimiento de los estados de entrega y registrar los comentarios de los clientes sobre su comida y/o nuestro proceso de entrega. Además, tal vez queramos saber qué comidas son las más (o las menos) populares. Y también debemos conservar cierta información financiera para fines de informes y análisis.
Supongamos que tenemos una aplicación que nuestros clientes pueden usar para realizar pedidos para entrega. Les permite elegir elementos del menú, pagarlos y especificar una hora y dirección de entrega. ¿Cómo sería el modelo de datos debajo de una aplicación de este tipo?
El modelo de datos
Puede abrir este modelo en su navegador haciendo clic en Edit model in your browser botón.
El modelo de datos consta de tres áreas temáticas:
Restaurants & customersMenusOrders
Presentaremos cada área temática en el orden en que aparece.
Restaurantes y Clientes
Los Restaurants & customers El área temática contiene tres tablas que almacenan detalles sobre nuestros restaurantes (puede haber más de uno), las ciudades donde operamos y nuestros clientes.
Tanto los clientes como los restaurantes están ubicados en ciudades (o pueblos, aldeas, etc.). Por lo tanto, necesitamos una city diccionario. Contiene solo dos atributos, city_name y zip_code . Si operamos en más de un país, también necesitaríamos un diccionario de países que estaría relacionado con esta tabla, pero no entraremos en eso aquí.
A continuación, necesitamos una lista de todos los restaurantes que operamos. Usaremos el restaurant mesa para eso. Para simplificar las cosas, solo almacenaremos la address de cada restaurante. y una referencia a la city donde se encuentra.
La última tabla en esta área temática es el customer mesa. Aquí es donde almacenaremos una lista de todos nuestros clientes de entrega registrados. Usaremos los datos de esta tabla para vincular a los clientes con sus pedidos más adelante en el modelo. Por supuesto, los clientes no tienen que estar registrados en nuestro modelo para realizar un pedido, pero aún necesitamos esta lista. Podríamos ofrecer descuentos a clientes registrados como programa de fidelización. O tal vez usaríamos estos datos para contactar a los clientes con ofertas especiales. Para cada cliente registrado, almacenaremos:
customer_name– El nombre completo del cliente.city_id– Hace referencia a lacitydonde vive el cliente.address– La dirección del cliente.contact_phone– El número de teléfono del cliente.email– La dirección de correo electrónico que el cliente utilizó durante el proceso de registro.confirmation_code– Un código de confirmación utilizado durante el proceso de registro.password– La contraseña seleccionada por el cliente para esta aplicación.time_joined– Una marca de tiempo de cuando el cliente se unió a nuestra aplicación.
Menús
Esta área temática contiene información sobre los menús de nuestros restaurantes. Por ahora, supongamos que todos nuestros restaurantes usan el mismo menú.
La primera tabla es la category diccionario. Contiene solo un atributo ÚNICO, category_name . Este campo probablemente contendrá las categorías habituales del menú, como "bebidas", "entradas", "ensaladas", "sándwiches", "pizza", etc.
A continuación, tenemos el menu_item mesa. Enumera todos los artículos que tenemos (o teníamos) en cualquiera de nuestros menús. Para cada artículo, almacenaremos:
item_name– Un nombre para ese elemento, p. “sándwich de pollo”.category_id– Hace referencia a lacategorya la que pertenece el artículo, p. “sándwiches”.description– Una descripción de ese artículo. Esto debería ser lo mismo que en el menú impreso.ingredients– Los ingredientes utilizados para producir ese artículo y sus cantidades. Este campo podría almacenar una receta.price– El precio actual de un artículo (por ejemplo, un sándwich de pollo).active– Si el artículo se ofrece en el menú actual.
Si queremos almacenar menús en varios idiomas, debemos usar un enfoque como el que se presenta en este artículo.
La mayoría de los restaurantes tienen ofertas especiales por tiempo limitado. También pueden tener algunas ofertas por tiempo ilimitado. Usaremos la offer mesa para estos. Para cada uno, tendremos:
date_active_fromydate_active_to– Juntos, estos definen cuándo está activa esta oferta. Si una oferta tiene una duración ilimitada o si se basa en horas en lugar de días, estos dos atributos contendrán valores NULOS. Un ejemplo de este tipo de oferta es "Durante el mes de marzo, compre un curry y obtenga otro con un 50 % de descuento".time_active_fromytime_active_to– Define la hora del día en que una oferta es válida – p. "Obtenga un café gratis de 6 a 9 a.m. todos los días".offer_price– El precio de esa oferta.
Todos los elementos del menú incluidos en las ofertas se almacenan en el in_offer mesa. Esta tabla contiene el par ÚNICO de offer_id – menu_item_id .
Si nuestros restaurantes tienen menús diferentes, necesitamos crear un menú separado para cada restaurante. Entonces necesitaríamos relacionar menús y ofertas con restaurantes usando claves foráneas. Esto nos permitiría cambiar los menús y ofertas de cualquier restaurante sin afectar a los demás. Esto no solo complicaría la base de datos; el modelo de negocio también se volvería más complejo. Esta es la razón por la que la mayoría de las cadenas de restaurantes se quedan con un solo menú y por la que decidí no usar este método en este modelo.
Órdenes
La última área temática en nuestro modelo es Orders área temática. Aquí es donde tendremos todo lo necesario para almacenar los pedidos y sus estados.
La tabla central aquí es el placed_order mesa. Es mejor no usar solo "orden" como el nombre de esta tabla:"orden" es una palabra clave de SQL. Trate de evitar el uso de palabras clave como nombres para tablas y columnas; de lo contrario, puede obtener errores al escribir consultas. Para cada pedido, registraremos:
restaurant_id– El ID delrestaurantrelacionados con esa orden.order_time– Una marca de tiempo de cuando se realizó el pedido.estimated_delivery_time– Una marca de tiempo de la entrega planificada de este pedido.food_ready– Una marca de tiempo que indica cuándo se prepararon los artículos del pedido. Esto contendrá un valor NULL hasta que se prepare la comida. Podríamos usar este atributo para calcular la diferencia de tiempo entre el momento en que se realizó el pedido y el momento en que se preparó la comida. También podríamos usarlo para encontrar cuánto tiempo transcurrió entre el momento en que la comida estuvo lista y la entrega. Esta información puede ser muy útil para aumentar la eficiencia del personal.actual_delivery_time– Una marca de tiempo de cuándo se entregó realmente este pedido. Será NULL hasta que se entregue la comida al cliente.delivery_address– La dirección donde se debe entregar el pedido.customer_id– El ID delcustomerquien hizo ese pedido. Este atributo podría contener un valor NULO si alguien que no es un usuario registrado de la aplicación realizó el pedido.price– El precio de todos los artículos incluidos en ese pedido.discount– El importe del descuento (p. ej., cupón o descuento por fidelidad) aplicado al precio, si lo hubiera.final_price– El precio del pedido menos el descuento.comment– Comentarios adicionales insertados por el cliente al realizar el pedido. Esto podría ser instrucciones de entrega adicionales o cualquier otra cosa que el cliente considere importante.ts– Una marca de tiempo de cuándo se insertó este registro en la tabla.
El in_order La tabla enumera todos los artículos u ofertas especiales que se incluyen en un pedido. Para cada registro de esta tabla, almacenaremos:
placed_order_id– El ID delorder.offer_id– Hace referencia a laofferpero sólo cuando una o más ofertas están incluidas en este pedido. En ese caso, elmenu_item_idel atributo será NULL.menu_item_id– Hace referencia almenu_itemtabla, pero solo si este registro está relacionado con un elemento del menú y no con una oferta.quantity– Cuántas ofertas o elementos del menú se incluyen en este pedido.item_price– El precio de una sola oferta o elemento del menú.price– El precio total de esta línea, expresado comoitem_price*quantity.comment– Cualquier comentario insertado por el cliente que se relacione específicamente con ese artículo de pedido, p. "Por favor, corte la pizza en 8 rebanadas".
El comment table nos permite admitir la inserción de múltiples comentarios relacionados con los pedidos. Para cada comentario, almacenaremos la ID del pedido relacionado y la ID del cliente. También almacenaremos una marca de tiempo de cuándo se ingresó este comentario. También marcaremos si este comentario fue una queja o un cumplido; solo uno de estos dos se puede configurar a la vez. Si no se establece ninguno, trataremos este comentario como neutral.
Las dos últimas tablas de nuestro modelo están relacionadas con los estados que asignaremos a los pedidos. El status_catalog la tabla contiene una lista de todos los status_name ÚNICOS posibles atributos que podríamos asignar a los pedidos. El order_status La tabla contiene todos los estados que se asignan a los pedidos. Para cada registro de esta tabla, almacenaremos claves externas relacionadas con el pedido y el estado y la marca de tiempo cuando se asignó este estado.
¿Qué opinas sobre el modelo de datos de entrega de restaurantes?
Hoy hemos discutido un modelo de datos que podría usarse para organizar, administrar y almacenar pedidos de entrega de restaurantes. Podemos rastrear el estado de cada pedido y algunos de los detalles financieros. Tengo algunas ideas sobre cómo podríamos hacer que este modelo sea más robusto, pero me encantaría escuchar su opinión. ¡Por favor compártelo en la sección de comentarios!
