Ir al contenido


Foto

[Sugerencia] Actualización de Data en Fondo


  • Por favor identifícate para responder
5 respuestas en este tema

#1 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 10 agosto 2018 - 09:52

Saludos.

 

En la aplicación que estoy desarrollando existe el concepto de Autorizar la Transacción. Esto consiste en cambiar el estado (campo numérico) del registro en cuestión (una transacción puede ser un recibo de caja, cheque, recepción de inventario, etc.. etc..)  y a su vez realizar CRUD en otras tablas pertenecientes al entorno de la transacción.

 

Mi idea inicial, consiste en que la aplicación solamente realice el cambio en el campo del estado al momento del usuario hacer clic en el botón de autorización, en otras palabras un burdo UPDATE a la tabla XX de la transacción; entonces alguien o algo realiza el CRUD necesario en el fondo (Background), tal vez no necesariamente la misma aplicación.

 

En esa parte del proceso es que necesito de su opiniones para ver cual sería la manera más factible de implementar.


  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 10 agosto 2018 - 01:40

Hola Rolphy, ¡Tanto tiempo sin tener novedades!

No se si es porque estoy dormido y cansado, es viernes, y estoy metido con tanto PHP que no termino de comprender tu duda.

¿Tu quieres que luego de hacer el update en el registro de una tabla, "algo" realice una serie de operaciones extras? ¿Algo externo a tu aplicación?

Si es eso, una posibilidad sería tener scripts .sql con las operaciones necesarias y pasarle los parámetros necesarios y mandarlo a ejecutar.

La otra es hacer una "aplicación esclava" que se dedique excluvisamente a hacer ese trabajo pesado y mandarla a ejecutar (lo mejor sería que fuera consola). Aunque esto supone el doble de esfuerzo ya que se necesita desarrollar no uno sino 2 sistemas.

No se si hay otras posibilidades. Quizá los que tienen más experiencia puedan opinar mejor.

Saludos,


  • 0

#3 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 11 agosto 2018 - 03:34

Que tal usando triggers de la BD?


  • 0

#4 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 14 agosto 2018 - 06:39

Que tal usando triggers de la BD?

Saludos.

 

Utilizando triggers los usuarios deben esperar a que la BD termine la ejecución de los comandos y justamente es lo que quiero evitar.

 

Lo que ando buscando es que se ejecuten en un "segundo plano", cuestión de que los usuarios no deban esperar a todo el CRUD y demás procesos que conlleve la transacción.


  • 0

#5 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 14 agosto 2018 - 06:50

Hola Rolphy, ¡Tanto tiempo sin tener novedades!

No se si es porque estoy dormido y cansado, es viernes, y estoy metido con tanto PHP que no termino de comprender tu duda.

¿Tu quieres que luego de hacer el update en el registro de una tabla, "algo" realice una serie de operaciones extras? ¿Algo externo a tu aplicación?

Si es eso, una posibilidad sería tener scripts .sql con las operaciones necesarias y pasarle los parámetros necesarios y mandarlo a ejecutar.

La otra es hacer una "aplicación esclava" que se dedique excluvisamente a hacer ese trabajo pesado y mandarla a ejecutar (lo mejor sería que fuera consola). Aunque esto supone el doble de esfuerzo ya que se necesita desarrollar no uno sino 2 sistemas.

No se si hay otras posibilidades. Quizá los que tienen más experiencia puedan opinar mejor.

Saludos,

 

Saludos amigo Delphius.

 

Sí un tiempo fuera del foro aunque siempre estoy pendiente de lo que ocurre.

 

Haz dado en el clavo, justamente es lo que ando buscando, una aplicación ("algo") que realice las operaciones extras necesarias de cada transacción y que el usuario no deba esperar a terminar dicho proceso.

 

Se pudiera ver como un doble esfuerzo, pero al final se debe hacer de todos modos ya sea que lo haga dentro de la misma aplicación o fuera de esta. Lo que ando buscando es "rapidez" delante del usuario, que no deba esperar tanto.

 

En cuanto a la aplicación esclava, creo que la aplicación principal no debería conocerla o sí? Pienso que debería de estar justo con la base de datos para ganar rapidez en la ejecución de los procesos.

 

¿Qué piensas?


  • 0

#6 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 14 agosto 2018 - 10:00

¿Que tan pesado es el trabajo "background"?

¿Tanto demora como para que el usuario lo sienta?

 

A veces creo que es mejor ser sincero con el usuario y decirle con un cartelito: "Este procedimiento lleva su tiempo. Por favor espere".

 

El tema de tener "algo" que por debajo haga la tarea puede complicarse si resulta que debe devolverse un resultado, confirmaciones, variables de control, o lo que la aplicación principal espera.

Si el algo es puro CRUD, altas, bajas, modificaciones, y no requiere de muchas bifurcaciones, ciclos, y otras complicaciones yo quizá consideraría en todo caso tener eso en un script .sql y mandarlo a ejecutar.

 

Lo de la aplicación esclava puede que si se necesite conocerla. O no. Depende de como lo estés pensando y diseñando.

Se puede lograr cierta independencia.

 

Si resulta ser que la aplicación principal pudiera continuar trabajando mientras se ejecuta ese "algo" y no dependa de algún resultado podría pensarse en algua tarea programada. Esto gana independencia. La tarea programada podría ejecutar esta aplicación esclava y evaluar si debe o no realizar alguna operación. Imagina algo como que se la aplicación principal "pone en cola" "cosas" por hacer, y luego la aplicación esclava está "escuchando" la cola y si no está vacia pues... aplica el CRUD.

 

Esta alternativa puede servir en ciertas ocasiones.

 

Saludos,


  • 0




IP.Board spam blocked by CleanTalk.