Base de datos por contingencia

[[AzidRain]]

Sea un sistema cliente basado en MySQL (básicamente facturación, logística y administración de transporte). Hay varias sucursales, todas conectadas directamente al servidor de la casa matriz. En diversas tablas se hace uso extensivo de claves autogeneradas para controlar algunos documentos (órdenes de cobro, números de embarque, etc.) Hay una tabla en especial, la de clientes, que es mantenida por todas las sucursales ya que todas dan de alta nuevos clientes todos los días De manera que en todas las sucursales tienen acceso a consultar información generada en cualquier otra prácticamente en tiempo real via internet.

Ahora bien, en el supuesto de que no haya conexión de internet, ninguna sucursal puede hacer nada en el sistema, ni siquiera loguearse pues no tiene acceso a la base de datos.

Estoy pensando en una forma de lograr que cada sucursal durante una contingencia de este tipo pueda seguir trabajando normal, lo cual no es problema pues con instalar un servidor local en cada una y activarlo en estos casos se resuelve. El problema viene cuando pasa la contingencia, nos encontraremos con bases de datos totalmente diferentes, en el caso de los clientes pudiera darse el caso de que un mismo cliente hubiera sido dado de alta 2 o mas veces en las sucursales debido a que no se tiene acceso al registro "maestro" por decirlo así.

El problema que quiero consultarles es como hacer un esquema que permita recuperar toda la información generada por las sucursales, y "normalizarla" para que siga con las numeraciones y demás que ya tenía el servidor maestro. He pensando en agregar una función para utilizarse en el programa conectado al servidor principal que reprocese cada tabla modificada, la copie a sus datos y le añada las claves que le toquen por decir algo si la sucursal x hizo ordenes de cobro del 1 al 100, copiar los datos y cambiarle del 5000 al 5100 que son los que le hubieran tocado de haber habido línea, obviamente haciendo todos los cambios en cascada a las tablas dependientes.
En cuanto a las facturas no hay problema porque son únicas para cada sucursal y en ese caso no son autoincrementados si no una combinación de un numero de folio y una serie que identifica la sucursal.


En MySQL ya probé la sincronización, pero no me sirve porque es de una sola vía aunque al final creo que será la única forma.

¿Alguna idea?

[[fjcg02]]

Sólo quería comentarte que lo que propones es la única alternativa posible.

En todos los sistemas que conozco en los que no se puede parar la producción en horario de atención al cliente ( cajeros automáticos, sucursales bancarias, tiendas con tpv , ... ) se utiliza el mismo modelo. Al irse la línea, se switchea el trabajo a una bbdd local, y una vez recuperada la línea, pasar a la bbdd general. Si es posible, un proceso en segundo plano hace la sincronización. Si no es posible, al finalizar la jornada y cerrar al público. Lógicamente, la funcionalidad operando en forma "off line" suele sufrir restricciones, ya que no suele ser posible realizar todas las funcionalidades. Debes tener en cuenta además, que para que funcione el off line deberás sincronizar tablas en local en una ventana horaria que no afecte al servicio; por ejemplo las tarifas,... y todo aquello que sea necesario. Te recomiendo que sea un proceso centralizado, de central a sucursales, en el que desde la central puedas comprobar que diariamente o con la periodicidad que necesites o configures se ha realizado correctamente la replicación de información. Y que además, puedas forzar cuando necesites a cualquiera de las sucursales.

Espero que te sirva de ayuda.

Un saludo

[[newtron]]

Hola.

El tema que propones es peliagudo.

Si no quieres o puedes usar replicación yo mantendría un campo en la base de datos local que determine si el registro se ha enviado a la central o no con lo cual podrías posteriormente hacer un procedimiento para integrar la información pendiente con los datos de la central renumerando en su caso los contadores que necesites y podrías intentar averiguar si un cliente o proveedor se ha duplicado haciendo una busqueda por su número de documento de identificación. El tema de las numeraciones también es delicado porque deberás de usar el mismo contador estando on/off line, es decir, o usas una tabla común ya estés conectado o no, o si van a trabajar en modo local le tocará al usuario poner manualmente los contadores de los documentos en la numeración correcta antes de empezar a trabajar on line. Igualmente, como te comenta nuestro amigo fjcg02 habrá información como las tarifas de artículos, descuentos, ofertas, clientes, etc. que necesites tenerlas actualizadas siempre para que se pueda trabajar en modo off line sin grandes problemas.

Saludos