Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   OOP (https://www.clubdelphi.com/foros/forumdisplay.php?f=5)
-   -   Como sincronizar datos entre bases datos cliente a servidor (asincronicamente) (https://www.clubdelphi.com/foros/showthread.php?t=82568)

Efren2006 20-03-2013 04:37:59

Como sincronizar datos entre bases datos cliente a servidor (asincronicamente)
 
Saludos a Todos

Coloco este tema para que me den una sugerencia, opinión o Idea con respecto a proyecto de sistema que debo realizar, debo realizar una aplicación donde los usuarios deben emitir como una especie de Guía o Orden de Trabajo, incluso imprimirla,, adicional controlar varias tablas, Reportes etc,,, el problema es que el cliente realiza dicha operación en unas oficinas que CASI existe Internet, es decir la comunicación no es muy buena ni estable, pero necesita que la información este prácticamente en Linea con su oficina principal., Pensé en hacer una aplicación como una tipo APP es decir como trabajan estas aplicaciones para móviles, que bajan la aplicación al equipo, pero la información se maneja vía Web... Por ahora solo conozco programar en Delphi 2009 y como BD Firebird...

Alguna sugerencia???

Chris 20-03-2013 05:53:44

Talvez te sirva un servicio como el de Firebase para guardar la información. Esto te evita construir el server side para guardar la información en un servidor web, que puede ser muy complicado sino sabes mucho de desarrollo de aplicaciones web.

Neftali [Germán.Estévez] 20-03-2013 11:28:39

El problema es que estás planteando dos afirmaciones que son opuestas.
Hay formas de trabajar, pero ninguna de ellas se cumple si tienes estas 2 premisas:

* el cliente realiza dicha operación en unas oficinas que CASI existe Internet, es decir la comunicación no es muy buena ni estable
* pero necesita que la información este prácticamente en Linea con su oficina principal.

O lo uno o lo otro, pero no puedes pretender que el programa trabaje en línea, si la conexión no es buena, porque lo que hagas tiene pinta de que va a fracasar.

Yo en caso de que el problema de línea no sea "solventable", optaría justo por lo contrario; Trabajar con datos "locales" que te aseguran conectividad y el buen funcionamiento del programa y en todo caso "en segundo plano" (otro proceso) que vaya recopilando y actualizando datos a intervalos regulares. En este segundo proceso será en el que tendrás problemas de conectividad (por lo que comentas de la línea), pero serán más fáciles de controlar que en la aplicación principal.

mamcx 20-03-2013 16:54:05

Lo primero, mas economico y mejor, seria que el cliente contratara un mejor servicio de internet.

Si algo es lento, mas CPU, mas RAM, mas ancho de banda, mas espacio en disco.

El hardware es mucho mas barato que el *desarrollo* de software!

------
Existen 2 formas basicas de resolver este caso.

La 1era, que ya apuntaron, es manejar los datos locales, y eventualmente, sincronizar contra el servidor de tu cliente. Para ello usas una BD como sqlite o firebird que son faciles de usar como datos locales (si aun no hay una BD elegida en el servidor de tu cliente, seria bueno que tanto el motor del servidor y del cliente sean el mismo. Menos trabajo).

OLVIDATE en este caso, de poder decir: Se cual es el inventario EXACTO EN ESTE MOMENTO.

La 2da, si los clientes tienen BUENA conexion a internet, y solo es la oficina de tu cliente la que la tiene mala, es tener la BD en la nube (osea, instalar la BD es un hosting de internet, vps, servicio cloud, lo que sea), programar normal los clientes contra el servidor en la nube, y que el cliente de la oficina use tambien esa BD.

Mejor dicho, todos son clientes (incluyendo la oficina de tu usuario) que usan un servidor externo (en la nube) que siempre esta disponible, tiene mejor ancho de banda y diponibilidad.

Efren2006 29-03-2013 01:56:18

Gracias a Todos por sus aportes e Ideas al proyecto,

Creo que optare por lo mas seguro,, trabajar locamente la BD, en este caso que técnica me sugerirían para sincronizar?

mamcx 29-03-2013 06:05:17

Diantre. Estas metiendote en algo que va ser facil o super difícil. Hacer BD distribuidas, es jodido. Hacerlas donde hay multiples escrituras y deben todas sincronizarse a un modelo estable y solido al final, es super super jodido.

De entrada: Lo mejor es simplemente que el cliente compre un mejor internet. Y que la BD este en un hosting aparte. No es una recomendación aleatoria pa ponerla en la lista de lindas ideas. Es la mejor opción, considerando la experiencia de muchos en este campo.

Pero porque hacerlo facil si se puede difícil? Pa eso programamos!!!!

P.D: Estoy en este momento pensando como resolver este mismo tema. Llevo *meses* investigando y mirando a ver si existe una solución *facil*. Pobre de mi.

----

El problema fundamental y mayor lio esta en la parte: "y la conexion se cae, luego se sincroniza" Repasa la paradoja de los 2 generales (Spoiler: Esta demostrado es imposible de resolver satisfactoriamente). Contrasta conque empresas como Apple han intentado resolver el punto, y les va mal. Existen algunas alternativas, como CouchDB -que no es para nada un motor sql- que pueden funcionar.

Osea, si hay operaciones asincronicas y poco fiables, se puede tornar el asunto muy serio. Y lo peor? Si no tienes mucha experiencia podrias no darte cuenta de lo serio hasta que empices a recibir llamadas constantes con quejas de informacion perdida, corrompida u obsoleta.

Enemigo #1: Datos asincronicos

El segundo problema es que hay mas de "una fuente de la verdad". Cuando hay un sistema "maestro:escritura-replica:solo lectura" es relativamente facil de resolver (es por eso que puedes hacer un cluster de BDs). En este modelo, el maestro es la definitiva "fuente de la verdad". Si un cliente esta corrompido, puedes reconstruir y compararlo contra el master, y la perdida de datos es local a solo ese cliente.


Aqui la *patada* es que tu maestro es un general ebrio, y propenso a perderse del radar! Por lo tanto, si el maestro esta fuera de combate, la informacion estara diseminada entre los clientes. Algunos clientes estaran mas adelante que otros, teniendo datos mas ciertos. Si te imaginas lo que implica un general en una batalla, ebrio, dormido, y poco fiable, pues eso es lo que describes.

Enemigo #2: Necesitas que sea un maestro-esclavos y dices que tu maestro es un inutil bueno para nada, a veces.


El tercero y mas comun es si los datos se actualizan simultanea y/o retroactivamente entre los clientes. Osea, 2 clientes pueden modificar el mismo registro, cuando les de la gana. Eso se resuelve facil en un sistema 2 niveles (con bloqueos o actualizaciones optimistas con resolucion de conflictos) pero estas metido con los otros 2.

Si *cada cliente* es dueño de sus propios datos en *independencia* de los demas o si los datos son "append/forward" entonces es *facil* incluso con los 3 lios juntos. Osea, es facil sincronizar solo inserciones. Sincronizar actualizaciones, y borrados, es lo que friega el asunto a niveles epicos.

Enemigo #3: Actualizaciones en conflicto-concurrentes (y dispares en el tiempo, pa rematar de ponerlo bonito).

---------
Reiterando la recomendacion anterior: La arquitectura externa de un sistema es *parte* integral de la eficacia del mismo. Una buena red, un buen configurado servidor, un motor de datos bien tenido, todo eso hace que el sistema opere *bien*. Cuando la infraestructura es correcta, los programas fluyen. Pero es cuando hay que darle vueltas para parchear (hackear) alrededor de las fallas de las infraestructuras que las cosa se ponen feas.

Sincronizar datos es posible. Pero no veo un escenario donde el maestro sea poco fiable y esperar que las cosas salgan bien. Si *definitivamente* es tan dificil pa tu cliente adquirir un mejor internet, la segunda mejor opcion es mover la BD central (el master) a un servidor en internet.

Luego, puedes aplicar varios modelos para sincronizar la informacion, pero es necesario saber un poco mas que tan "freago" es tu caso (ej: como son los datos, si se puede o no particionar por cliente, si hay lios de relaciones, mas bien, un esquema general de como es la BD).

Considera, que este camino es mas esforzado en programacion y testeo. Como te conte, llevo meses evaluando que hacer, porque francamente, preferiria no cojer ese camino (en mi caso, es necesario, si quiero, como deseo, que BestSeller pueda ser usado por cientos de personas con o sin conexion de internet... aunque por otro lado, podria desechar la idea de que funcione sin internet, y !bingo! problema resuelto).

Casimiro Notevi 29-03-2013 12:36:11

Resumiendo lo explicado por mamcx:
Si el puente está lleno de agujeros, no contrates helicópteros, ni lances a las personas con cañón al otro lado, ¡¡¡arregla el puente!!!
Está claro, si el problema es que se corta internet, ¡¡¡arréglalo!!!


La franja horaria es GMT +2. Ahora son las 01:44:08.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi