Ver Mensaje Individual
  #8  
Antiguo 13-11-2013
bucanero bucanero is offline
Miembro
 
Registrado: nov 2013
Ubicación: Almería, España
Posts: 208
Reputación: 13
bucanero Va camino a la fama
Hola, dispongo de un sistema similar a lo que intentas implementar, funcionando ya hace algun tiempo (casi dos años), que permite el proceso de sincronización entre nuestra central y las distintas delegaciones que disponemos (tiendas).

El sistema consta de un servidor de internet con una BD en MySQL, (BD común donde cada delegación recoge y vuelca sus datos) y las delegaciones disponen de sus propia BD en local en un servidor MS-SQL SERVER con un software de gestión de terceros que no me permite realizar modificaciones a la estructura de dichas BD (locales), por lo que he tenido que adaptar todos los sistemas de control para la sincronización a la BD remota que yo si puedo gestionar.

PROCESO GENERAL DE SINCRONIZACIÓN:

Para el control de la sincronización, a cada tabla del servidor remoto le he añadido tres campos adicionales:
-MD5 de tipo string(32): Guarda un valor HASH de los campos de datos que se han sincronizado
-Updated de tipo TimeStamp: Guarda la fecha y hora que se actualizo
-Deleted de tipo boolean: Indica si este registro ha sido borrado
De tal forma que a la hora de realizar el proceso de comparación de datos uso dos Querys (Origen y destino) uno conectado a la BD remota y otro a la BD local, y solamente me descargo los índices de la tabla (campos PRIMARY KEYS), y el campo MD5, de la BD remota y en la BD local pongo los campos índices (PRIMARY KEYS) y una función que me calcula el valor MD5 de los campos de datos de cada registro. En ambos casos ordeno por los valores indice, y ya simplemente se trata de recorres ambos QUERYS simultáneamente aplicando un algoritmo de mezcla.

Según se va recorriendo encontraras las siguiente situaciones:
· El primary key esta en las dos tablas:
o El MD5 es igual en ambas tablas´: el registro esta ya actualizado y no ha cambiado nada, por tanto no se hace nada y se pasa al siguiente registro
o El MD5 es distinto: los datos de origen y destino han cambiado. Se actualizan los datos de la tabla de destino, y en caso de ser el destino el servidor remoto también se actualiza el valor del MD5
· El primary key solo esta en el origen:
o Es un nuevo registro y se añade a la tabla de destino, insertando también el valor del campo MD5 si se trata del servidor remoto.
· El primary key solo esta en el destino: Se trata de un registro antiguo que ha sido borrado.
o Se borra de la tabla si es el servidor local o se marca como deleted si son los datos del servidor remoto
Los datos completos del registro solamente los cargo cuando se ha producido alguna modificación o es necesario dar de alta un nuevo registro, de esta forma el trafico de red no es muy alto, puesto que solo descarga completamente aquellos registros que han sido modificados o añadidos.

TIPOS DE TABLA:

En función del tipo de datos que contiene las tablas me encuentro con las siguientes opciones:
· Tablas que se actualizan completamente desde un sitio al resto por ejemplo desde la CENTRAL a las tiendas, aquí se pueden incluir como ejemplo, las tablas de Articulos, precios, categorías, etc…, este es el proceso mas simple de todos, puesto que los datos se traspasan íntegramente desde un sitio al otro sin mas problemas y sin necesidad de control de delegación.
· Tablas que se actualizan parcialmente, donde cada delegacion actualiza sus datos y recoge los datos de las otras delegaciones, por ejemplo clientes, ventas, stocks, etc. Para este caso es necesario que el PRIMARY KEY o INDICE de la tabla contenga un campo identificador de la delegación, y el proceso de actualización se realiza en dos pasos:
* Primero se mandan nuestros datos a la BD remota, para que estén disponibles al resto de delegaciones, por lo que la consulta de índices la filtramos a delegación=nuestra

* Y finalmente se actulizan los datos que tenemos guardados del resto de delegaciones en la BD local nuestra, filtrando la consulta de indices para que delegación<>nuestra
Este sistema que yo dispongo esta sincronizando algo mas de 100 tablas de media con unos 5000 registros la mayoría y algunas tablas con mas de medio millón de registros, en un tiempo medio de unos 10 minutos, creo que consiguiendo una velocidad de sincronización bastante alta .
Responder Con Cita