[quote=404064:@Bernardo Monsalve]Tengo experiencia con la opción A) con cierta diferencia, funciona bien, cuando la base de datos está cerca de los clientes, en mi caso, <100ms ping, recuerde usar conexiones seguras, y aunque no lo recomiendan (conectarse directamente a la DB desde internet) monitoreando la red y con contrafuegos, tiene buen rendimiento.
Problemas: cuando c cae la conexion con un proveedor, normalmente el cliente tiene un proveedor de respaldo (con menos capacidad, digamos por móbil) y la aplicacion está monitoreando constantemente la conexion (un “SELECT 1;”) y en casos críticos graba localmente y cuando vuelve a conectarse, c actualiza.[/quote]
Yo he implementado algo similar y mi solución fue trabajar siempre sobre un estado local que se sincroniza cada vez que puede.
El concepto “sincronización” es un nido de serpientes, así que hay que irse con mucho cuidado. Todos los problemas que no existen en local (concurrencia) y en remoto (gestión automática de peticiones) adquieren un cariz muy raro en la sincronización.
La ventaja es que permite mucha flexibilidad. Especialmente en clientes móviles. El truco, obviamente es minimizar las escrituras (y eliminar la capacidad de escribir a registros maestros) y poner timestamps a casi todo.
La aplicación local ni siquiera sabe, en su mayor parte, que existe la base de datos remota. Todo lo trabaja en local. Un proceso separado es el que se encarga de ir consultando el estado remoto y de hacer el intercambio cuando puede.
La velocidad al ser 100% local es ideal. Haciendo bien el “protocolo” de timestamping puedes minimizar enormemente el flujo de datos.
Esencialmente lo único que trabaja sobre la base de datos principal es cualquier dashboard que pongas para monitorizar globalmente.
Es exactamente como funcionan todos los clientes de correo de las últimas tres décadas, incidentalmente. La clave es el concepto de “paquete de información único” con fechas (un mail, un contacto, un evento).