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...@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