¿Como permitir trabajar offline si se cae el servidor?

[AzidRain]

Tengo una aplicación totalmente probada y en producción desde hace ya algunos meses, trabaja mediante MySQL y Zeos y los clientes se distribuyen en diferentes sucursales ubicadas en diferentes ciudades, solo una sucursal tiene acceso "local" en la misma red física en que se encuentra el servidor, las demás lo hacen remotamente.

Hasta ahora nunca he tenido problemas de servidor caído, falla en el medio o la conexión, energía eléctrica en el servidor, etc. pero nunca está por demás pensar en lo peor.

Estoy tratando de pensar en alguna forma de hacer que todas las sucursales puedan seguir operando aún sin que esté levantado el servidor. El problema es que la base de datos gestiona casi 60 tablas y hace uso extensivo de claves autoincrementadas las cuales se utilizan para identificar de manera única diversos registros (clientes, órdenes de pago, recibos, etc.) por lo que no quisiera que pasada la contingencia se produjeran errores de integridad en la base de datos. Por otro lado, ¿Como hacer el cambio del servidor principal a otro y que sea transparante para el usuario?

Alguna vez instale un servidor esclavo y me funcionaba bien, pero el detalle es que solo replica en un solo sentido, se podía seguir trabajando en el esclavo de cada sucursal pero al momento de actualizar el principal aparecian claves duplicadas (dado que se generaban independientemente).

No se si me dí a entender

[movorack]

Hola azid,

Podrias usar UUID (http://en.wikipedia.org/wiki/Universally_unique_identifier) para las claves primarias.

MySQL soporta UUID y tiene dos funciones integradas:

UUID_SHORT() (http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-functions.html#function_uuid-short) y UUID (http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-functions.html#function_uuid)

de esta manera salvarias la parte de las llaves y no tendrias problemas de colisiones.

[Al González]

Respecto a las claves autoincrementadas, hay que preguntarse si las necesitas para llevar números consecutivos o solamente para darle unicidad a los registros. Muchas veces se confunde una cosa con la otra y queremos que todas las llaves primarias de una tabla vayan de forma consecutiva, cuando lo único que necesitamos es que sean únicas.

Si fuera este último caso, convendría establecer un rango razonable de claves para cada sucursal, o que dichas claves se compongan o lleven un indicador de qué sucursal la generó. Si el tipo de campo usado no permite hacer lo anterior, cambiarlo por uno más flexible y usar generadores (secuencias) si fuese oportuno.

Dependiendo de las complejidades del trabajo “sin conexión”, es posible que te convenga usar conjuntos de datos clientes (TClientDataSet), pues estos tienen la capacidad de almacenar la información en archivos locales para posteriormente, cuando estemos conectados nuevamente, enviarla al servidor de la base de datos.

Esa parte de los conjuntos de datos clientes es algo que no he manejado aún, pero sé que existe, y la ayuda de Delphi viene con algo de información al respecto. En cualquier caso siempre recomendaré el uso de TClientDataSet y DBX, pues esa mancuerna ofrece una gran cantidad de ventajas sobre otros componentes de acceso a datos, tanto nativos, como de terceros. Desconozco qué tanto los has estudiado, César. :)

No sobra decir que también recomiendo evitar el uso de claves "visibles" (que representan algo para los usuarios) a manera de llaves primarias. En mi opinión estas últimas tienen como único requisito que sean únicas (aunque no sean consecutivas) y no tienen nada qué hacer en una pantalla o en un reporte (para el usuario sencillamente no existen). Una cosa es el campo ID de una tabla (el que le da unicidad a cada registro y los identifica ante la base de datos y el código de la aplicación) y otra es el campo Clave, Numero, Codigo, etc. (el que le da a cada registro "identidad" ante los usuarios).

Mi respuesta es algo simple para lo que seguramente tendrás que afrontar, sin embargo espero sirva de algo.

Saludos.

Al González. :)

[Neftali [Germán.Estévez]]

Tema muy complejo en el que te metes...

Ya no sólo por los registros que insertes nuevos y los problemas que posteriormente vas a tener poara sincronozarlos con los del resto de sucursales y con los que ya hay en la Base de Datos. Sobre este tema ya te han comentado cosas.

Lo otro que debes afrontar es las claves existentes en la Base de Datos que necesitas como foráneas para tus registros nuevos. Eso significa que debes tener una copia actualizada de la Base de Datos (o de ciertas tablas) en local; Al menos de las maestras. Si no es de todas, eso limitaría tus acciones. Eso añade además el trabajo de tener la Base de Datos replicada en la sucursales y un proceso continuo para actualizarla.

No se si me explico. Dependiendo de los datos que necesites, esa copia puede ser pequeña o la Base de Datos completa.

Una cosa más que debes tener en cuenta.

[pcicom]

Creo que en la PRACTICA es mas SENCILLO que puedas tener una SEGUNDA forma de RESPALDO de conexion o para mantener la CONEXION, a que quieras realizar una conexion temporal...

Si te conectas por INTERNET por medio de un PROVEEDOR DSL.. que contrates otra conexino con OTRO PROVEEDOR de esa manera unicamente intercambiarias la conexion y LISTO... estarias nuevamente FUNCIONANDO..

Y obviamente por el metodo de conexion LOCAL es un tema sumamente complicado he implica un REANALISIS PROFUNDO de tu APLICACION.. para poder cubirir estos menesteres...

SALUDOS Amigo..