Closed jmramirezG closed 1 year 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.
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!
Sí, suena bien eso que dices del diccionario.
Me parece bien hacerlo así.
Genial!
Gracias por el feedback, en cuanto pueda me pongo a desarrollar entonces :)
Una pregunta @jmramirezG, ¿realmente el número de comensales de la mesa nos hace falta para algo en este problema?
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:
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.
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.
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!
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í.
Ya si a JJ le parece bastante simplista, recuperamos esta conversación más adelante, pero como primera iteración me parece bien.
Este issue no está ni enlazado ni guiado por ninguna historia de usuario.
Todo issue que cerréis y no lo hagáis desde un commit va a daros error de ahora en adelante.
Oído
Pues reábrelo y ciérralo (desde un commit) cuando tengas menester.
Hola @iscoct!
Modelo de datos
En principio vamos a definir las siguientes estructuras de datos para el M1, directamente relacionadas con #32 :
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í:
Y te dejo un par de dudas aquí:
Espero tu respuesta y feedback el modelo planteado!