Ir al contenido


Foto

off-line, on-line, juntos


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

#1 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 02 marzo 2016 - 05:56

Hace poco comencé a trabajar en un nuevo proyecto al que en clave lo llamé 12R1, no me pregunten por qué le pongo las claves, supongo que es para poder nombrarlo en Facebook y que no hagan uso inadecuado de su futuro nombre.

 

El asunto es que quiero cumplir con una característica que me está rompiendo la cabeza. Al principio parece sencilla, pero a soluciones sencillas, resultados ineficientes. Recuerdo que en la facultad un profesor nos enseñó a diferenciar muy bien eficacia y eficiencia.

 

Quizás alguien pueda aportar alguna idea o ayuda. El problema:

 

Una aplicación se comunica con una base de datos en un servidor que centraliza la información, a este mismo servidor se conectarán varias aplicaciones con propósito semejantes. Pero, cuando la aplicación no pueda comunicarse con el servidor, deberá tener conectividad con una DB local y una copia de la DB central que se actualiza cada tanto (diariamente). Con esto se supone que la aplicación puede seguir operando en forma desconectada para luego, al retomar la conexión llevar los datos generados al servidor y seguir operando normalmente.

 

El problema, se presenta con los generadores de claves primarias de las instancias de entidad que se vayan creando en el modo off-line.

 

En un principio, la solución es trabajar siempre off-line y hacer un sondeo sobre la actividad del servidor e ir escribiendo por ráfagas en momentos de inactividad. Esto implica recrear en la DB central, los registros que se realizan en la DB local.

 

¿alguien hizo algo parecido?

 

Saludos

 


  • 0

#2 genriquez

genriquez

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 539 mensajes
  • LocationCali, Colombia

Escrito 02 marzo 2016 - 07:24

En principio yo siempre trato de tener seriales de claves diferentes para cada "Sede",  así no tendría conflictos de seriales.,   Ej. las claves de la sede 01, siempre serían 01xxxx, etc.

 

si no es posible, se le asigna una clave "local", temporal, y cuando se puede conectar se modifica, asignándole la clave "Global" final.

 

En cuanto a la copia de la base de datos,  procuro no hacerlo, ya que esto implica un desgaste grande de los canales de comunicación,  usualmente tengo una tabla en el servidor, donde está el nombre de la tabla y la última fecha de modificación, y luego cada registro tiene la fecha de modificación,    y de cuando en cuando, realizo la comparación entre la tabla del servidor y la local,  actualizando solo los registros modificados desde la última fecha.   Esto especialmente lo hago con maestros.

 

La ventaja de trabajar en 3 capas, es que conectarse con un servidor local o uno remoto puede ser transparente y la otra ventaja es que puedes guardar los datasets con las modificaciones y posteriormente abrirlo y actualizarlos, casi sin ningún código adicional.

 

Si requieres más detalles me avisas.

 

Saludos.


  • 1

#3 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 02 marzo 2016 - 08:12

Gracias Gustavo, lo de concatenar valores para obtener una clave única fue una de las soluciones propuestas, pero el problema que surgió es que al crear esos IDs, nuevos en la db del servidor podrían "chocar" con los IDs. creados en la db local aun estando encabezadas con -por ejemplo- el número de sucursal.

 

El tema de no copiar los datos es que si la db local no tiene aquellos datos que están relacionados con los que pretende registrar, no podrá hacerlo hasta tener conectividad. En fin, no se trata de hacer una copia constantemente, sino de una actualización continua y a pequeños pasos.

Obviamente, lo ideal es trabajar en línea con el servidor central, pero cuando "cae" la conexión, no se puede decir al cliente, "no puedo venderte, no hay sistema", como se acostumbraron a decir por acá. Y escribir todo a mano para luego pasarlo al restablecerse la conexión, no es nada bueno, menos cuando hay una impresora fiscal con las responsabilidades fiscales conocidas.

 

(b)


  • 0

#4 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 02 marzo 2016 - 08:52

Porque en vez de tener una base de datos local, no guardas archivo con la informacion..Osea si es un insert guardas un archivo xml por ejemplo.

Y si es un update tendrias que buscar la manera de guardar el cambio...y para los select cada dia guardas un archivo de tablas

 

No se bien de que trata tu aplicacion,que es lo que gestiona.. pero indudablemente es mucho mas complicado tener un servidor de base de datos en local...

Es complejo trabajar con bd distribuidas.. tengo entendido hay que saber "replicacion de bd"

 

Igualmente, existen 2 tipos de actores me parece a mi: los que ingresan datos con los insert por ejemplo, y los que consumen la informacion...Para mostrar la informacion correctamente se deben tener los datos actualziados en la base de datos central de todos los lugares donde opera el sistema.


  • 0

#5 genriquez

genriquez

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 539 mensajes
  • LocationCali, Colombia

Escrito 02 marzo 2016 - 09:20

La ventaja de los DbExpres y FireDac, es que ya tienen las funciones incorporadas, si le dices al dataset   savetofile,  guardas el archivo con los inserts, los deletes, etc.  y luego de cargarlos con un load from file puedes hacer un applyupdates y listo.

 

 

IDs, nuevos en la db del servidor podrían "chocar" con los IDs. creados en la db local aun estando encabezadas con -por ejemplo- el número de sucursal.

 

 Los Id es cuestión de manejo, igualmente si tienes una base de datos local, puedes llevar por sede el número del consecutivo, si se cae la conexión, los usuarios de la sede al menos podrían tener un consecutivo que no se repita,  igualmente se puede hacer por vendedores, cada vendedor tiene su propio consecutivo, así no se repetirían.

 

 

El tema de no copiar los datos es que si la db local no tiene aquellos datos que están relacionados con los que pretende registrar, no podrá hacerlo hasta tener conectividad. En fin, no se trata de hacer una copia constantemente, sino de una actualización continua y a pequeños paso

 

Se trata de copiar los datos estrictamente necesarios, no toda la base de datos, creo que las tablas de transacciones no son necesarias en la mayoría de las operaciones con cara al cliente, a no ser la estadística como cartera y esas cosas.

 

Es cuestión de manejo, creo yo.


  • 0

#6 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 02 marzo 2016 - 11:28

Interesante tema; nunca lo he implementado, pero por el momento solo veo dos alternativas viables, una ya la han comentado por aca

 

La otra forma creo que seria, seguimos grabando en modo offline (en la BD local), genero mis propios Id; luego, cuando tengo conexion, mando todo eso a Insert; pero no haria "caso" al Id que quedo generado en local, eso seria una clave temporal; yo creo que lo correcto seria seguir con la correlatividad del servidor; implicaria obviamente una vez que se inserta en el central, que este responda cual es el Id que debo colocar en local y actualizar todos los registros

 

Una tercera alternativa, no estoy seguro que tan viable podria ser, es el uso de GUIDs como claves primarias (podria degradarse la performance?)


  • 0

#7 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 02 marzo 2016 - 06:27

Gracias por las sugerencias. Seguiré trabajando en eso. Veo que no estoy muy fuera de foco, pero se que me falta bastante. Eso sí, de poder implementarlo sería una gran característica (claro por aquí, ya que hay conectividad pésima)

El problema es que cada vez que creo hallar la solución, ésta o es definitiva, aparece alguna cosilla.

 

Saludos.


  • 0




IP.Board spam blocked by CleanTalk.