Actualizar información en otra terminal

[Jeronimo]

¡Hola!
Estoy en un sistema donde se cargan pedidos en una terminal y deben verse reflejados en otra para cobrarlos y tener un control de los pedidos que se van cargando. Es un sistema que funciona en red local con MySQL.
¿La mejor forma de hacerlo es mediante un timer que ejecute la consulta cada x segundos/minuos?
Siempre pensé que los timers que ejecutaban consultas constantemente hacían la cosa más pesada. ¿Conviene hacerlo así?
Muchas gracias.

Jerónimo

[LeandroA]

Hola, en el sistema donde trabajo el usuario presiona un boton para actualizar, al principio pensa porque no ponian un timer, pero si sacas la cuenta de todas las computadoras que hay en cada sucursal es logico que no se use un timer, ademas la computadora suele quedar prendida con el soft prendido y serian consultas al pepe.

por otro lado pensa tambien si el sistema esta lento, y se desea usar el aplicativo de forma local esas consultas podrian poner en peligro su funcionamiento.

igualmente evalua tu caso.

[YAcosta]

Hola Jerónimo, te comento.
En mi soft todos los pedidos se hacen por red, el cliente mas grande tiene 8 pcs para pedidos, en el módulo que levanta estos pedidos hay un control label que cambia de color porque se hace la consulta por segundo (usando un timer) para saber si hay pedidos en cola, al cambiar de color el usuario hace clic y levanta otro form con los pedidos y procede con la transacción.
Ahora, ¿es lento? para nada, ni pizca ¿porque? porque la consulta es contra dos tablas intermedias que nunca crecen, los pedidos de los usuarios llegan a esa tabla que es a la que consulto por segundo, en el minuto pico no habrían mas de 20 registros en la tabla cabecera, ahora, cuando levanto el pedido y se convierte en venta dicho pedido la meto a otra tabla de pedidos históricos y la borro de la tabla intermedia por eso digo que no crece. Todo esto ya desde mas de 5 años y por este tema cero problemas, sinceramente cero problemas.

En otros sistema que controla 3 tiendas y cada tienda con +/- 10pcs y con una BD que pesa casi 500 megas, tiene en un formulario que opera como un tablero de mando y al ser netamente informativo poblando 2 grids y actualizando 2 gráficos todo por segundo (timer), solo cuando el usuario quiere interactuar con ese módulo por ejemplo para cambiar rango de fechas o aplicar algún filtro en las consulta, entonces presiona un botón que pone el timer en enabled false. Este modulo si hace consultas pesadas, pero no hay riesgos porque estamos hablando de un motor serio (al nivel de MySQL) y ademas las transacciones se ejecutan correctamente, sino fuera así no habrían pasado con este soft mas de 2 años sin problemas.

Entonces, considero que no son los timers los que hacen las consultas pesadas, eso depende totalmente de las consultas en si (de los querys) y de que se hace con ellas (si se recorren nos ponemos mas lentos), entonces, en el contexto que explicas habría que entender como quieres expresar la funcionalidad, si quieres actualizar por segundo un grid (eso daría problemas para interactuar con ese grid) o si quieres usar alguna especie de led avisando del nuevo pedido. Mientras mas ágiles sean las consultas mucho menos problemas habrían, el asunto es volver ágil la operación.

Lo que no entiendo es la problemática que comenta nuestro estimado amigo Leandro, pero en todo caso como bien dice debes evaluar el caso porque las realidades de nuestros sistemas no son las mismas.


Saludos.

[Albertomi]

Estimado Jeronimo

En mi caso un sistema de Taxi que consta de un módulo (Call Center) desde donde se registran las llamadas de solicitudes de taxi y otro módulo de despacho desde donde se asignan en forma automática y/o manual las solicitudes de taxi al taxista más cercano o al que han indicado el cliente. El sistema funciona a nivel nacional, con una única DB centralizada y actuamente desde la nube.

Inicialmente el módulo de despacho tenía un timer que actualizaba la cola de despacho, pero esto poco a poco fue afectando el rendimiento general ya que el número de operadores en el Call center aumento por lo que la cantidad de consultas que se lanzan contra el motor de DB también aumentaron dramáticamente por la frecuencia con la que se tenía que mantener actualizada la grilla en la que se refleja la cola de solicitudes de taxi.

La solución fue crear un servidor para la aplicación, todos los módulos inician sesión contra este servidor y es este servidor quien remotamente se encarga de mantener actualizada la grilla de la cola de solicitudes de taxi. Te explico, cuando desde el Call Center registran una solicitud de taxi el servidor es el que se encarga de ingresarlo a la DB vía un SP la solicitud de taxi cuando termina de insertar la solicitud el servidor le envía un mensaje a todas las PC cliente que iniciaron sesión con el módulo de despacho y se actualice la información de la grilla de solicitudes de taxi.

Saludos, desde algún lugar en Lima - Perú

[raul338]

Estan en red "local"? Hay otra forma también (se puede complementar con el timer y el boton actualizar), enviar un mensaje al broadcast (ni idea como se dice en español) por sockets udp

Esto es así, es como tener otro canal de comunicacion mandando un aviso de "che, ya actualize, vo' fijate..." por red aparte de la conexion de la base de datos y otras conexiones...

Entonces vos tenes una PC que revisa las consultas nuevas (etc...) cuando le llega un mensaje de alguien, las demas PC terminales que efectuan el pedido tambien lo reciben, pero no deberian hacer nada

Mirá esto: elGuille - Broadcast mediante UDP: Enviar mensajes a toda una red utilizando Winsock

Es más facil que implementar toda una conexion cliente/servidor para algo tan simple, igual no siempre llegan los mensajes (un 90% ya que no hay control de llegada del mensaje)

No se si me llego a entender, tiene que haber algún video que explique eso por youtube (?

[cobein]

Y no se puede poner un triger que actualice una tabla donde se guarde por ejempo, nombredb, timestamp de la modificacion, y luego consultar el timestamp de modificacion y ver si es diferente al que tenemos en el programa?. Digo para no "recargar todo" permanentemente

[Albertomi]

Estimado raul338

El inconveniente con el Broadcast es si la red de nuestro amigo esta segmentada, en ese caso el Broadcast no va llegar a todas las PC. Pero si es una interesante alternativa para una buena LAN no segmentada.
 
Saludos, desde algún lungar de Lima-Perú

[seba123neo]

siempre va a haber una persona fisica usando la pc donde se facturan, asi que la solucion es un simple boton de actualizar o que consulte cada 1 minuto, con eso ya esta, y si la pc queda prendida toda la noche pues que la persona deshabilite esa actualizacion automatica mediante algun parametro y listo.

[cobein]

Mucho mas simple, podes consultar asi

Select TABLES.UPDATE_TIME from information_schema.`TABLES`
WHERE TABLE_SCHEMA = '<TU BASE>' AND TABLE_NAME = '<TU TABLA>'

Eso devuelve el timestamp de la ultima modificacion, Ese timestamp lo comparas con el local y si cambio hay que hacer un refresh y guardar el nuevo timestam. Aca me funciono solo en las bases que usas MyISAM y no el las de InnoDB

Edit: Todo esto siempre y cuando tengas accso a  information_schema

[seba123neo]

esa tabla solo esta disponible desde mysql 5 en adelante, si tenes la version 3.51 que era la anterior mas usada no va, pero igual hoy es recomendable usar la ultima version, porque mysql no le da mas soporte a esa version vieja.

[Jeronimo]

¡Qué bueno, muchachos, cuánta información!
Son todas buenas soluciones.
El sistema es para un restaurante que, además, tiene una fiambrería tipo gourmet. Entonces, en la fiambrería se hacen pedidos, se corta el fiambre o se preparan los productos que se van a vender (hay varios vendedores, por lo que habrá varios pedidos casi simultáneamente) y luego, en la caja, se cobran. Como la caja tamién está pendiente de lo que sucede en el restaurante, puede que se acumulen pedidos de la fiambrería para cobrar. Entonces, lo que quiero es que la lista de pedidos de la fiambrería, así como todo lo inherente a las mesas del restaurante (esos datos los carga el camarero en su compu), se vayan actualizando en la pc de la caja. No serán muchas mesas ni muchos pedidos de la fiambrería que se acumulen (me refiero a no más de 20 mesas y 10 pedidos), ya que se irán cobrando.
En principio pensaba (a ver qué les parece) tener una variable con el número del último pedido (ID) para el caso de la fiambrería. Luego, mediante un timer que se dispare cada 10 segundos, buscar en las tablas correspondientes los datos actuales de las mesas (como dije, no serán muchas) y el ID máximo de la tabla de pedidos. Si ese valor fuera mayor que el de la variable, ahí buscaría los datos y actualizaría el listado.
Lo que no sé es si luego de unos años buscar el ID máximo de una tabla de miles de registros o los datos de 20 mesas en una tabla de miles de registros no se tornará lento. Si fuera así, entonces me parece que la mejor opción sería, como dice Yván, manejar las mesas en curso y los pedidos nuevos en una tabla provisoria y, luego de cobrarlos, pasarlos a una tabla definitiva.
Si no, de todas las sugerencias me parece que la de cobein es la más práctica y factible para este caso.
¿Qué les parece?
Muchas gracias.

[ssccaann43]

Buenas tardes, espero no sea tarde para dar mi punto de vista aca...

Inicialmente cuando generas un pedido este debe tener un status el cual identifica si el pedido ha sido facturado o cobrado o esta en status por cobrar. Esto sin mensionar si el pedido es Anulado.

Ahora bien, cada vez que creas un pedido lo que deseas es mostrarlo en la caja? Simple.

Si trabajas usando el campo Status, y lo que quieres es que se listen de manera automatica, pues inicialmente crea una VISTA en tu BD para que genere la consulta y muestre los registros, desde visual basic usa un timer que realice la consulta a la vista y muestre solo los pedidos segun el Status que tu consideres. Esto puede hacerse cada 5 seg.

Aun cuando tu tabla tenga 2 millones de registros, la vista no generara problemas para mostrar los registros, obviamente si tienes una base de datos bien armada, es decir normalizada.

En un cliente me toco desarrollarle un software que automaticamente vaya actualizando los registros y mostrandolos en graficas, pues facilmente hice lo que te estoy recomendando. No es gran cosa, es decir no te dara problemas.

Cualquier duda, consultanos.

Saludos a todos.