Aplicacin de escritorio en dos escenarios

Quiero desarrollar una aplicacin con base de datos, me gustara conocer sus recomendaciones. Se trata de una aplicacin de escritorio en dos escenarios:

A) La aplicacin ejecutada desde varios equipos interactuando con un servidor de base de datos (PostgreSQL) alojado en la nube.
B) La aplicacin ejecutada desde varios equipos interactuando con SQLite local y replicando al resto de los equipos.

Cul de los escenarios sera la mejor opcin? Por el momento el desarrollo de una aplicacin web queda descartada, aproximadamente serian 30 equipos clientes trabajando simultneamente.

Gracias anticipadas por su retroalimentacin.

Tengo experiencia con la opcin 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 mbil) y la aplicacion est monitoreando constantemente la conexion (un “SELECT 1;”) y en casos crticos graba localmente y cuando vuelve a conectarse, c actualiza.

[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).

Para conexiones remotas con base de datos, siempre, siempre usa tunel ssl o VPN. Es súper arriesgado publicar un servidor de bases de datos a internet.

Mejor todava: Ni siquiera pienses que existen conexiones a bases de datos remotas. Siempre monta un API intermedio que se comunique. Nada del cliente debera llegar al servidor de base de datos sin haber sido procesado.

Ni siquiera con tunel, porque eso sigue necesitando un servidor “conectable” por red. La nica conexin del servidor tiene que ser a la misma mquina a un proceso que la gestione, y este se habla con el que gestiona peticiones remotas.

A no ser que sea en LAN, ningún cliente debería conectar directamente contra una BBDD remota… sino hacerlo a través de una API. Aparte de mayor seguridad, también aporta mayor flexibilidad; si cambias de motor/esquema de BBDD, sólo tendrás que modificar la capa de la API, no los clientes…

Javier

[quote=404133:@Javier Menéndez]A no ser que sea en LAN, ningún cliente debería conectar directamente contra una BBDD remota… sino hacerlo a través de una API. Aparte de mayor seguridad, también aporta mayor flexibilidad; si cambias de motor/esquema de BBDD, sólo tendrás que modificar la capa de la API, no los clientes…

Javier[/quote]
Si, eso recomiendan, pero mi experiencia muestra otros escenarios, durante años, 5 mínimo, conozco no una, sino decenas de basedatos postgres, asegurado con SSL Monitoreando constantemente TODAS las conexiones entrantes, y aparte de mucho HTTP y wordpress tratando de buscar “huecos”, no he tenido un sólo ataque contra postgres, ni siquiera el puerto 5432 (ahunque NO se usa ese puerto), tal vez he tenido buena suerte, pero, cómo c explica entonces los ataques HTTP??, (yo creo que la IP q asigna el proveedor ya está en una “lista negra” y la conocen los atacantes, porque son nuevos dominios en nuevos proveedores con nuevas IPs… ??)

Una alternativa: construir un servicio en el servidor y que los llamados a base de datos sean en realidad consultas al servicio. Si se cae internet, inmediatamente se sabe. no tienes problema de ir a dejar una transacci´øn en la mitad de algo y tiene la ventaja de que puedes consumir incluso si es local.

Bueno hay muchas formas de hacer las cosas, la que ud. propone está bien, sin embargo hay operaciones (sobre todo OLTP) donde cambian mucho las tablas, y c necesita esta actualizada en todo momento, para que colocar otro servicio, que c tiene que configurar y mantener además de programar cuando c puede hacer de una forma segura con SSL? y lo d transacciones, pues bien sea que c inicie una transaccion local o en un procedimiento en la BD, la transacción c ejecuta TODA o no c ejecuta independientemente de donde c inicie (cleinte o servicio).

yo he tenido que hacer APIs (http/json) que consumen clientes externos, pero son bastante puntuales y especializadas y son muy pocas realmente. Esa es mi experiencia :wink: