Si hay una forma de pedir comestibles en línea, ¿por qué no usarla? Este artículo examina el modelo de datos detrás del sistema de entrega de una tienda de comestibles.
Todavía tenemos una sensación especial al elegir algo del jardín y luego prepararlo de inmediato, pero no es algo que podamos hacer a menudo. El ritmo acelerado de hoy no lo permite. De hecho, a veces ni siquiera nos permite ir a la tienda a “recoger” la compra. Así que tiene sentido ahorrarnos algo de tiempo y usar una aplicación para pedir lo que necesitamos. Nuestro pedido aparecerá en nuestra casa. Tal vez no obtengamos esa sensación especial de recién cosechado, pero habrá comida en nuestra mesa.
El modelo de datos detrás de dicha aplicación es el tema del artículo de hoy.
¿Qué necesitamos para un modelo de datos de entrega de comestibles?
La idea de este modelo es que una aplicación (web, móvil o ambas) permita a los clientes registrados crear un pedido (compuesto por productos de nuestra tienda). Entonces este pedido será entregado al cliente. Obviamente, almacenaremos los datos de los clientes y una lista de todos los productos disponibles para respaldar esto.
Los clientes pueden realizar múltiples pedidos que incluyen diferentes artículos en diferentes cantidades. Cuando se recibe el pedido de un cliente, se debe notificar a los empleados de la tienda para que puedan encontrar y empacar los artículos necesarios. (Esto puede requerir uno o más contenedores). Finalmente, los contenedores se entregarán, ya sea juntos o por separado.
En la propia aplicación, los clientes y empleados deberían poder insertar notas y calificar a la otra parte después de que se haya realizado la entrega.
El modelo de datos
El modelo de datos consta de tres áreas temáticas:
Items & unitsCustomers & employeesOrders
Presentaremos cada área temática en el orden en que aparece.
Sección 1:Artículos y Unidades
Comenzaremos con los Items & units área temática. Aunque es una pequeña parte de nuestro modelo, contiene dos tablas muy importantes.
La unit La tabla almacena información sobre las unidades que asignaremos a cualquier artículo en nuestro inventario. Para cada valor de esta tabla, almacenaremos dos valores ÚNICOS:unit_name (por ejemplo, "kilogramo") y unit_short (por ejemplo, "kg"). Observe que unit_short es la abreviatura de unit_name .
La segunda tabla en esta área temática es item . Enumera todos los artículos que tenemos en el inventario. Para cada artículo, almacenaremos:
item_name– El nombre ÚNICO que usaremos para ese artículo.price– El precio actual de ese artículo.item_photo– Un enlace a una foto de este artículo.description– Descripción textual adicional del artículo.unit_id– Hace referencia a launitdiccionario y denota la unidad utilizada para medir ese artículo.
Tenga en cuenta que he omitido algunas cosas aquí. La más importante es una bandera que indica si un artículo del inventario se ofrece actualmente para la venta. ¿Por qué no tenemos esto? Requeriría al menos un campo adicional (la bandera), así como otra tabla (para almacenar cambios históricos para cada elemento). Para simplificar las cosas, asumí que todos los artículos que tenemos en el inventario también están disponibles para vender.
La segunda cosa importante que omití es rastrear el estado del almacén. Mi suposición es que enviamos todo desde un almacén central y que siempre tendremos artículos disponibles. Si no tenemos un artículo, simplemente se lo notificaremos al cliente y le ofreceremos un artículo similar en reemplazo.
Sección 2:Clientes y empleados
Los Customers & employees El área de asunto contiene todas las tablas necesarias para almacenar datos de clientes y empleados. Usaremos esta información en la parte central de nuestro modelo.
El employee La tabla contiene una lista de todos los empleados relevantes (por ejemplo, los empacadores de comestibles y los repartidores). Para cada empleado, almacenaremos su first_name y last_name y un employee_code ÚNICO valor. Aunque la columna de identificación también es ÚNICA (y la clave principal de esta tabla), es mejor usar otro valor del mundo real (por ejemplo, un número de IVA) como identificador de empleado. Así tenemos el employee_code campo.
Tenga en cuenta que no he incluido los detalles de inicio de sesión de los empleados, los roles de los empleados y una forma de rastrear el historial de roles. Estos se pueden agregar fácilmente, como se describe en este artículo.
Ahora agregaremos clientes a nuestro modelo. Esto tomará dos mesas más.
Los clientes se segmentarán geográficamente, por lo que necesitaremos una city diccionario. Para cada ciudad en la que ofrecemos entrega de comestibles, almacenaremos el city_name y el postal_code . Juntos, forman la clave alternativa de esta tabla.
Los clientes son definitivamente la parte más importante de este modelo; ellos son los que inician todo el proceso. Guardaremos una lista completa de nuestros clientes en el customer mesa. Para cada cliente, almacenaremos lo siguiente:
first_name– El nombre del cliente.last_name– El apellido del cliente.user_name– El nombre de usuario que el cliente seleccionó al configurar su cuenta.password– La contraseña que el cliente eligió al configurar su cuenta.time_inserted– El momento en que este registro fue insertado en la base de datos.confirmation_code– Un código que se generó durante el código de registro. Este código se utilizará para verificar su dirección de correo electrónico.time_confirmed– Cuándo ocurrió la confirmación por correo electrónico.contact_email– La dirección de correo electrónico del cliente, que también se utiliza como correo electrónico de confirmación.contact_phone– El número de teléfono del cliente.city_id– El ID de lacitydonde reside el cliente.address– El domicilio del cliente.delivery_city_id– El ID de lacitydonde se debe entregar el pedido del cliente.delivery_address– La dirección de entrega preferida. Tenga en cuenta que esto puede ser (pero no tiene que ser) el mismo que el domicilio del cliente.
Sección 3:Pedidos
La parte central y más importante de este modelo son los Orders área temática. Aquí encontraremos todas las tablas necesarias para realizar un pedido y realizar un seguimiento de los artículos hasta que se entreguen a los clientes.
Todo el proceso comienza cuando un cliente realiza un pedido. Una lista de todos los pedidos realizados se encuentra en el placed_order mesa. Utilicé intencionalmente este nombre y no "pedido" porque pedido es una palabra clave reservada de SQL. Para cada pedido, almacenaremos:
customer_id– El ID delcustomerque realizó este pedido.time_placed– La marca de tiempo cuando se realizó este pedido.details– Todos los detalles relacionados con ese pedido, en formato de texto no estructurado.delivery_city_id– Una referencia a lacitydonde se debe entregar este pedido.delivery_address– La dirección donde se debe entregar este pedido.grade_customer&grade_employee– Calificaciones dadas por el empleado y el cliente después de completar un pedido. Hasta ese momento, este atributo contiene un valor NULL. La calificación de un cliente indica qué tan feliz estuvo con nuestro servicio; la calificación de un empleado nos brinda información sobre qué esperar la próxima vez que el cliente haga un pedido.
Durante el proceso de realizar un pedido, un cliente seleccionará uno o más artículos. Para cada artículo, definirán una cantidad deseada. Una lista de todos los artículos relacionados con cada pedido se almacena en el order_item mesa. Para cada registro en esta tabla, almacenaremos ID para el pedido relacionado (placed_order_id ), elemento (item_id ), la cantidad deseada y el price cuando se realizó este pedido.
Además de qué quieren que se les entregue, los clientes también definirán la hora de entrega deseada . Para cada pedido, crearemos un registro en la delivery mesa. Esto registrará el delivery_time_planned e inserte notas textuales adicionales. El placed_order_id El atributo también se definirá cuando se inserte este registro. Los dos atributos restantes se definirán cuando asignemos esa entrega a un empleado (employee_id ) y cuándo se entregó el pedido (delivery_time_actual ).
Si bien puede parecer que solo tendremos una entrega por pedido, es posible que no siempre sea así. Es posible que necesitemos hacer dos o más entregas por pedido, y esa es la razón principal por la que elegí poner los datos de entrega en una nueva tabla.
Cuando comenzamos a procesar un pedido, los empleados empacarán los artículos en una o más cajas. Cada box se definirá ÚNICAMENTE por su box_code y se asignará a una entrega (delivery_id ). También almacenaremos la identificación del empleado que preparó esa caja.
Cada caja contendrá uno o más elementos. Por lo tanto, en el item_in_box tabla, necesitaremos almacenar referencias al box tabla (box_id ) y el item tabla (item_id ), así como la cantidad colocada en esa casilla. El último atributo, is_replacement , indica si un artículo es un reemplazo de otro artículo. Podemos esperar que un empleado se comunique con un cliente antes de colocar un artículo de reemplazo en una caja. Un resultado de esa acción podría ser que un cliente esté de acuerdo con el artículo de reemplazo; otro podría ser la cancelación de todo el pedido.
Las tres tablas restantes del modelo están estrechamente relacionadas con estados y comentarios.
Primero, almacenaremos todos los estados posibles en el status_catalog . Cada estado se define ÚNICAMENTE por su status_name . Podemos esperar estados como "pedido creado", "pedido realizado", "artículos empacados", "en tránsito" y "entregado".
Los estados se asignarán a los pedidos de forma automática (después de que se completen algunas partes del proceso) o, en algunos casos, manualmente (por ejemplo, si hay un problema con el pedido). Todos los estados de pedidos disponibles se almacenan en el order_status mesa. Además de claves foráneas de dos tablas (status_catalog y placed_order ), almacenaremos la marca de tiempo real cuando se asignó este estado (status_time ) y cualquier details adicionales en formato textual.
La tabla final en este modelo son las notes mesa. La idea detrás de esta tabla es insertar todos los comentarios adicionales relacionados con un pedido dado (placed_order_id ). Los comentarios pueden ser insertados por empleados o clientes. Para cada registro, solo uno de los employee_id o customer_id los campos contendrán un valor; el otro será NULL. Guardaremos el momento en que se insertó esta nota en el sistema (note_time ) y el note_text .
¿Qué cambios haría en el modelo de datos de entrega de comestibles?
Hoy discutimos un modelo de datos que podría admitir aplicaciones de entrega de comestibles móviles y web, tanto desde la perspectiva del cliente como desde la del empleado. Como ya se mencionó en este artículo, hay muchas maneras de mejorar este modelo. Siéntase libre de agregar sus sugerencias. Cuéntanos qué le agregarías o quitarías a este modelo. O tal vez organizaría esta estructura de manera completamente diferente. ¡Háznoslo saber en la sección de comentarios!
