[Objetivo-2] Problema de representación de los datos para la HU1

jmramirezG commented 2 years ago

Hola @iscoct!

Modelo de datos

En principio vamos a definir las siguientes estructuras de datos para el M1, directamente relacionadas con #32 :

Bebidas
- Nombre
- Código
Postres
- Nombre
- Código
- Ingredientes
- Pasos de elaboración
Entrantes
- Nombre
- Código
- Ingredientes
- Pasos de elaboración
Primeros platos
- Nombre
- Código
- Ingredientes
- Pasos de elaboración
Segundos platos
- Nombre
- Código
- Ingredientes
- Pasos de elaboración
Comandas
- Mesa
- Timestamp
- Comida
- Entrantes
- Primeros
- Segundos
- Bebidas
- En espera (comidas y bebidas que no están siendo elaborados aún)
- En proceso de elaboración (comidas y bebidas que faltan por estar disponibles para entrega pero se están elaborando)
- Listos para entrega (comidas y bebidas que estan disponibles para entrega)
- Entregados (comidas y bebidas que han sido entregadas a la mesa)
Mesa
- Numero de mesa
- Comensales
Camarero
- Nombre
- Código
Chef
- Nombre
- Código

Creo que los temas de "procesado" (no marcar los platos como listo para entregar hasta que no se hayan terminado de preparar todos los de la categoría, por ejemplo) deberíamos dejarlos para más adelante, una vez quede definida la estructura que vamos a usar.

Te clarifico algunos detalles sobre porqué lo he planteado así:

Las comandas deberían tener el timestamp para saber quién ha llegado primero y se ha sentado en mesa, de forma que una mesa que haya llegado antes, sea servida con prioridad frente a una que haya llegado más tarde.
Las comandas serían editables, siendo el camarero el que, tomando nota, añade/retira elementos de la comanda.
Las comidas contendrían nombre, código, ingredientes y pasos de elaboración para facilitar la labor de los chefs.
Las mesas solo indican el número de comensales y un código identificativo, el número de mesa.

Y te dejo un par de dudas aquí:

Las bebidas no tienen pasos de elaboración, deberían tenerlos?
Respecto al personal, creo que no haría falta más información, indicame si faltara algo para añadirlo.

Espero tu respuesta y feedback el modelo planteado!

iscoct commented 2 years ago

Me parece genial eso del timestamp, creo que es acertado incluirlo para tenerlas en una lista ordenada como bien dices.

Creo que aunque has declarado los estados para las comandas, estaría bien tener algún tipo de ENUM, como estado o algo así que marque esos tipos que dices. Si lo quieres dejar así, al menos, debería tener sólo 3 tipos, de tal manera que si no está en espera, no está entregado y tampoco listo para entregar, se puede suponer que están en proceso de elaboración. De todas formas, creo que un enum sería mejor.

Sobre la bebida, no tengo claro si debiera tener pasos de elaboración. Podrían tenerlos los cócteles complejos, ¿sabes? Pero el proceso que tengo en mente de optimizar es el proceso de la comida, que suele tardar bastante más. No creo que aporte mucho valor (que nos ahorre mucho tiempo) indicar pasos para realizar un cóctel. ¿Cómo lo ves?

Creo que el personal por ahora está bien también, deberíamos de añadir los pasos a realizar por los platos pero eso lo haré en el futuro como está marcado en la lista de milestone, me parece bien así por ahora.

Estoy pendiente a tus respuestas @jmramirezG para seguir comentando la estructura de datos.

jmramirezG commented 2 years ago

Creo que aunque has declarado los estados para las comandas, estaría bien tener algún tipo de ENUM, como estado o algo así que marque esos tipos que dices.

Si lo quieres dejar así, al menos, debería tener sólo 3 tipos, de tal manera que si no está en espera, no está entregado y tampoco listo para entregar, se puede suponer que están en proceso de elaboración.

De todas formas, creo que un enum sería mejor.

Sin problema entonces, hacemos un ENUM.

De hecho, así pensando, ¿que te parece la opción de hacer un diccionario para cada comanda con clave el plato y valor el estado del mismo (si no tiene es que no está aún)? Siendo el estado un valor del ENUM, obviamente.

Si no podemos tirar simplemente por el enum en el estado de cada plato, inicializado a vacío y ya se va rellenando conforme avanza por cocina hasta llegar al cliente.

Sobre la bebida, no tengo claro si debiera tener pasos de elaboración.

Podrían tenerlos los cócteles complejos, ¿sabes? Pero el proceso que tengo en mente de optimizar es el proceso de la comida, que suele tardar bastante más.

No creo que aporte mucho valor (que nos ahorre mucho tiempo) indicar pasos para realizar un cóctel.

¿Cómo lo ves?

Perfecto! Dejamos entonces la bebida sin pasos de elaboración y listo.

Coméntame cuál de las dos ideas relativas al ENUM te parece mejor y comienzo a implementar!!

Muchas gracias!

iscoct commented 2 years ago

Sí, suena bien eso que dices del diccionario.

Me parece bien hacerlo así.

jmramirezG commented 2 years ago

Genial!

Gracias por el feedback, en cuanto pueda me pongo a desarrollar entonces :)

iscoct commented 2 years ago

Una pregunta @jmramirezG, ¿realmente el número de comensales de la mesa nos hace falta para algo en este problema?

iscoct commented 2 years ago

He estado pensando en la estructura de datos necesaria y te comento algunas cosillas que creo que deberíamos discutir:

Bebidas: Sólo necesita el campo nombre, por lo general no va a necesitar un ID para identificar aparte la bebida. No tengo claro si en base de datos debería tenerlo, pero como modelo no debería haber 2 bebidas que se llamen igual, si son 2 iguales y cambian las cantidades, al ser una bebida podríamos poner por ejemplo "Coca Cola Zero" y si varios tamaños "Coca Cola Zero 1 litro, o algo así pero no creo que haga falta el ID.
Los platos creo que debería ser:
- Plato: Nombre, Tipo

Agrupando de esta manera entrantes, primeros platos, segundos platos y postres. Realmente no va a hacer distinción entre el tratamiento de los distintos platos, sólo debemos saber el tipo para saber qué platos deberán salir primero y cuales no. Además, sobre los pasos, creo que esa parte la podemos dejar para más adelante porque para los primeros entregables (milestone) no nos va a hacer falta.

Mesa: El número de comensales para lo que pretende solucionar nuestro sistema, no tiene importancia, por lo que creo que no debería estar. Si ves alguna funcionalidad que no pudiera existir al no tener el campo comensales, déjamelo saber.
Chef, Camarero, etc.: Realmente distinción entre camarero, chefs u otros, no vamos a hacer. Sólo nos hace falta saber quién se va a dedicar a hacer ciertos pasos de los platos y quién se dedica a las bebidas. Por tanto, propongo que lo modelemos como:

Empleado: Id, Nombre ResponsablePasos: IdPaso, IdEmpleado

Por otra parte, para los primeros milestones, como no se va a tener en cuenta los pasos, tal vez podamos crear sólo Empleado, y en un futuro hago ResponsablePasos.

Por último, Comanda debe de tener un campo Estado, porque como se dijo que queríamos saber qué platos quedan por preparar, debe de tener Estado para saber si están EN_ESPERA, PREPARANDOSE, PARA_ENTREGAR o ENTREGADO.

iscoct commented 2 years ago

De hecho, dudo ahora mismo también de que debamos de modelar Empleado ahora mismo porque para los primeros milestone, no vamos a hacer ninguna distinción según las responsabilidades de los empleados.

Al principio todos los empleados recibirán todas las comandas que quedan por entregar con todas las bebidas y comidas de esa comanda.

jmramirezG commented 2 years ago

Estoy completamente de acuerdo en que realmente no necesitaremos un identificador para las bebidas, no debería ser necesario ni siquiera para temas de la BD.

Incluir el tipo en los platos también me parece buena idea, así condensamos un poco, ya que al fin y al cabo tienen los mismos atributos, lo suyo sería que tuviesen la misma tabla en la BD. También dejaré los pasos fuera de momento, si cambias de opinión, siempre puedes responderme por este issue.

En lo que respecta al estado de la comanda, comentamos esto en este mismo hilo:

Sin problema entonces, hacemos un ENUM.

De hecho, así pensando, ¿que te parece la opción de hacer un diccionario para cada comanda con clave el plato y valor el estado del mismo (si no tiene es que no está aún)? Siendo el estado un valor del ENUM, obviamente.

Si no podemos tirar simplemente por el enum en el estado de cada plato, inicializado a vacío y ya se va rellenando conforme avanza por cocina hasta llegar al cliente.

No se cómo de viable será, si lo prefieres simplemente metemos el estado en la comanda a forma de un único estado por comanda y listo, sin problemas.

El empleado lo dejaré ya hecho, así te ahorro trabajo más adelante, aunque no sea gran cosa.

Comentame que te parece. Muchas gracias!

iscoct commented 2 years ago

Perfecto, sobre el estado de la comanda, podemos dejarlo así en el Milestone 1, que el estado esté en la comanda, me parece poco granular porque hasta que no estén las bebidas y las comidas no va a quitarse todo lo que está preparado, pero como primera iteración lo podríamos dejar así.

iscoct commented 2 years ago

Ya si a JJ le parece bastante simplista, recuperamos esta conversación más adelante, pero como primera iteración me parece bien.

JJ commented 1 year ago

Este issue no está ni enlazado ni guiado por ninguna historia de usuario.

JJ commented 1 year ago

Todo issue que cerréis y no lo hagáis desde un commit va a daros error de ahora en adelante.

iscoct commented 1 year ago

Oído

JJ commented 1 year ago

Pues reábrelo y ciérralo (desde un commit) cuando tengas menester.

iscoct / cotan