Re: Qt5 & SQLite
On 2020-08-11 at 13:14 -0300, JavierDebian wrote:
>
> El 11/8/20 a las 01:04, Felix Perez escribió:
> > El lun., 10 de ago. de 2020 a la(s) 17:21, JavierDebian
> > (javier.debian.bb.ar@gmail.com) escribió:
> >>
> >
> > La solución que estudiamos en su momento, fue que los clientes
> > locales, al cerrar el día generaban un reporte, el reporte se enviaba
> > a casa matriz junto a una copia de la BD, se almacenaban las copias de
> > la BD para auditoría y los reportes alimentaban el servidor central,
> > un RH (no recuerdo versión), propusimos instalar un Mysql. No me
> > acuerdo que lenguaje se propuso, pero parece que querían seguir
> > utilzando BBx ya que tenían un par de desarrolladores con mucha
> > experiencia en él.
> > Todo el sistema el antiguo y el nuevo eran transparentes para el
> > usuario, a punta de batch del lado de windows y de scripts del lado
> > del servidor. Lo único que fallaba era cuando se cortaba la energía
> > eléctrica en algún local y este no contaba con UPS o generador.
> > Se me ocurre Firebird embebido o sqlite en los clientes locales, y un
> > servidor central con Mysql o Postgresql.
> >
> >
> > Deberás automatizar todo lo que puedas, no darle opciones al usuario.
> >
> > Suerte, espero que te sirvan un poco mis recuerdos.
> >
> >> JAP
> >>
>
>
> Como te dije, esto es justamente lo que quiero hacer.
> La programación va a ser en Qt5, de eso, no tengo dudas.
> Lo que me "pica" es el motor de base de datos; aún no me he decidido.
> Si el sistema bajo DOS ha durado casi 20 años, lo que haga supongo que
> durará otros 20; tengo que pensar en algo que se mantenga en ese lapso.
> C++ lo va a hacer, y espero que Qt5 también; hay mucho de base que
> dependen del primero, y bastante del segundo.
> Las bases de datos, son otra cosa.
> Me estoy debatiendo entre MaríaDB (por su parentesco con MySQL), SQLite
> (por su liviandad), y Firebird (por su potencia).
>
> Le sigo dando vueltas.
>
> JAP
Te aconsejo no limitarte en demasía y usar una interfaz tal que
posteriormente puedas cambiar el módulo que te provee la base de datos
sin problemas. Todos estos sistemas usan SQL, y es posible escribir
código SQL compatible con todos ellos (cuidado, que algunas extensiones
de SQL no las soportan todos los motores!). Tendrás seguramente también
funciones para usar prepared statements, etc. pero en general las API
deberían ser relativamente similares, por lo que puedes hacer un
desarrollo para una BBDD pero de que costara relativamente poco cambiar
luego a otra distinta (o incluso hacerlo compatible con varios, por
ejemplo es común en proyectos que soportan múltiples backends que en
producción usen un mysql o postgres pero para instalaciones pequeñas de
desarrollo trabajen con sqlite).
Lo que no me queda muy claro es cómo deberían funcionar las oficinas
"aisladas". Una opción sería simplemente enviar listar las consultas SQL
pendientes y enviar los paquetes en la fase de sincronización de los
datos (al final del día, cuando recuperen la conexión, etc.). En
realidad, la replicación de mysql se basa exactamente en esta idea.
Pero si además de "añadir datos", van a tener que hacer consultas, etc.
necesitarán además una versión "local" de la base de datos, con una
capacidad de sincronizar los datos entre todas (si es que hace falta).
Posiblemente te enfrentes un sistema multi-master. Si en realidad cada
oficina cambia solo los datos "propios", no tiene por qué ser demasiado
complicado, pues en realidad vendrían ya particionados (eso sí, no
podrías usar autoincrementals sino por ejemplo GUID) y con que una
oficina no pueda cambiar datos de otra, deberías mantener la
consistencia (al nivel de actualización de los datos de cada una,
claro), pero es una cosa a tener en cuenta. Si en cambio, la oficina
central actualiza los precios en una tabla central que use cada oficina,
pero cada una la actualiza en un momento diferente, dependiendo del
momento en que se sincronizaran, un producto puede variar de precio
según la sucursal. Puede haber muchas cuestiones a prever.
Y, sobre todo, te aconsejo que en los informes que se saquen de forma
central aparezca bien claro la fecha de actualización de los datos de
esa oficina... para cuando los directivos de turno hagan búsquedas
combinadas de diferentes sucursales pero en realidad no estén todas al
día.
Un saludo
Reply to: