Ver Mensaje Individual
  #6  
Antiguo 18-09-2024
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is online now
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 19.440
Reputación: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por Yps Ver Mensaje
En cuanto a lo del "pooling" la explicación a sido buena, aunque no sé cómo hacerlo, si no es mucho pedir podrías enviarme algún enlace donde se explique como implementarlo. Realmente me interesa!!

El "pooling" no es más que lo que ha comentado [Casimiro]. Ir preguntando periódicamente por el estado de algo para saber si ha sufrido cambios (en este caso los cambios en la tabla).
La implementación con un Timer o con un thread separado.

Lo que si considero importante es, que si la tabla de la que quieres refrescar el Grid es muy grande, no pregunte directamente a la tabla (refrescando el grid), sino que lo hagas con una tabla secundaria (pequeña y de acceso rápido). Por ejemplo, si tienes una tabla de OPERACIONES que visualizas en un grid y quieres mantenerla actualizada, pero es grande, te creas una segunda tabla pequeña con esta estructura:

HAY_CAMBIOS_OPERACIONES
-------------------------------------

ID; Autonumerico;NOT NULL
ULTIMOCAMBIO; FechaHora; NOT NULL

1) Cuando hay un cambio en la tabla de operaciones, haces un INSERT en la tabla HAY_CAMBIOS_OPERACIONES
2) El pooling o el Timer hace la consulta sobre la tabla HAY_CAMBIOS_OPERACIONES, en lugar de sobre la tabla de OPERACIONES
(esto sale a cuenta si la tabla de OPERACIONES es pesada/grande y las consultas costosas)
a) Si la tabla HAY_CAMBIOS_OPERACIONES tiene registro, actualizas el GRID y borras ese registro
b) Si la tabla HAY_CAMBIOS_OPERACIONES NO tiene registros es que no habido cambios y no hay que hacer nada más.

Lo dicho, esta tabla HAY_CAMBIOS_OPERACIONES sale a cuenta mantenerla si la tabla OPERACIONES es grande y no quieres estar continuamente generando esas consultas costosas. Si la taba original (OPERACIONES) es pequeña o la consulta se hace con filtros y no es costosa, esta técnica de usar una segunda tabla no es necesaria.

Esta es la idea simple, hay variantes, como que la tabla HAY_CAMBIOS_OPERACIONES, sea más genérica y te pueda servir para más tablas. En este caso el TimeStamp no haría falta estrictamente, sólo que exista registro, etc, etc, etc,... (el ejemplo es simple y rápido para explicar la idea, no es una implementación final).

Espero que la idea se haya entendido.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita