PDA

Ver la Versión Completa : Como sincronizar dos Bases de Datos (SQLite y PostgreSQL)


JoAnCa
08-09-2014, 20:02:22
Hola a Todos
Tengo una aplicación que usa SQLite y necesito obtener los datos de otra aplicación que usa PostgreSQL, para la primera vez esta bien importar todos los datos de una para la otra, pero después solo necesito los datos nuevos, es decir soncronizar las 2 bases de datos

Los datos de las tablas que necesito, no siempre se modifican por eso necesito saber primero si se modificó alguna tabla o no, para en caso positivo obtener solo los datos nuevos o modificados de la BD Origen

Uso componentes los ZEOS para conectarme a ambos (SQLite y PostgreSQL) y Delphi7

Casimiro Notevi
08-09-2014, 20:46:52
Lo más simple es poner un campo a las tablas que necesites sincronizar. Ese campo puede ser booleano o 1/0. Si es 1 es que hay que pasar el registro a la otra BD. Cuando se pase lo pones a cero.
Por ejemplo.

Combat-F2D
09-09-2014, 07:42:07
no te olvides de controlar las excepciones y posibles errores, es decir, dentro de transaciones

pacopenin
09-09-2014, 12:32:15
Si la sincronización es en una sola dirección opino como Casimiro. Otra cosa sería una sincronización bidireccional. Aún así, ojo con los registros borrados.

Neftali [Germán.Estévez]
09-09-2014, 16:44:06
Lo más simple es poner un campo a las tablas que necesites sincronizar. Ese campo puede ser booleano o 1/0. Si es 1 es que hay que pasar el registro a la otra BD. Cuando se pase lo pones a cero.
Por ejemplo.

Una variante a esto (la he utilizado) es utilizar un campo de TimeStamp en la Base de Datos origen y en la destino.
Eso te permite comparar los datos que ya has traspasado y evita los UPDATES en la BD origen en el momento de traspasar.

JoAnCa
09-09-2014, 20:51:15
El problema es que no tengo control de la BD Origen (Postgres), pues es un soft de terceros, y en mi empresa quieren hacer un modulo que usa los datos de varias tablas de ese sistema, por eso en el sistema origen no puedo tocar nada, solo leer los registros que me interesan, y verificar si son iguales o no a los de mi BD (SQLite) para importar los nuevos o modificados

Casimiro Notevi
09-09-2014, 22:00:12
Pues ya depende de lo que puedas leer.
Tienes que hacer como MacGyver :D ¿de qué dispones?, pues ahora a sacarle provecho a lo que tienes :)

Los registros que puedes leer tendrán un campo id único, se supone, pues aprovéchate de ellos para crear tú unas tablas con unos campos que te indiquen si ya lo has importado o no.

Neftali [Germán.Estévez]
09-09-2014, 23:41:45
El problema es que no tengo control de la BD Origen (Postgres), pues es un soft de terceros, y en mi empresa quieren hacer un modulo que usa los datos de varias tablas de ese sistema, por eso en el sistema origen no puedo tocar nada, solo leer los registros que me interesan, y verificar si son iguales o no a los de mi BD (SQLite) para importar los nuevos o modificados

Pues entonces tendrás que copiar todos al sincronizar o realizar una comparación con todos los campos de cada registro para saber los que se han modificado y los que no. Esto último dependiendo de los registros totales de la tabla y de los modificados, te saldrá a cuenta o no.

Es decir, lo explico con un ejemplo.

Si la tabla son 200 registros y has modificado 100, te sale a cuenta no hacer la comparación y actualizarlos todos.
Si la tabla son 100.000 registros y has modificado 500, te sale a cuenta hacer la comparación.

newtron
10-09-2014, 09:38:33
Pues qué queréis que os diga pero yo veo una locura detectar en una tabla con unos cuantos miles de registros qué se ha modificado, borrado o insertado.

Igual te resultaría más "realista" poner límites a lo que quieres hacer y dedicarte por ejemplo a "importar" registros por fechas a la nueva base de datos pero claro, no sé lo que necesitas.. ¿sincronizar totalmente? ¿añadir registros nuevos? ¿también modificados? ¿anulados?..uffff....

Neftali [Germán.Estévez]
10-09-2014, 11:43:04
Entiendo que no es un proceso que se haga "en vivo", es decir continuamente, sino cada x tiempo (estoy pensando 1 vez al día, 1 vez a la semana,...).
¿Es así?

pacopenin
10-09-2014, 12:12:44
Entiendo por lo que pones en el primer post que la primera vez se pasan todos los datos y luego solo los nuevos. Opciones que se me ocurren:

Si en la base de datos origen hay campos de fecha de creación, guarda en tu base de datos la fecha de la última actualización y añade sólo los posteriores a dicha fecha.
Si la base de datos origen tiene campos Id autoincrementados, utiliza esos mismos en la tuya y añade sólo a partir de el último id importado.
Sino? a pensar. Necesitaríamos más información.Si no hay actualizaciones ni borrados debería bastar. En caso contrario, volveríamos al punto tercero.

JoAnCa
12-09-2014, 15:46:39
Gracias a todos por las respuestas y disculpen la demora en responder, es que no habia tenido tiempo de conectarme

Pues le detallo el problema
En la BD origen necesito las tablas de trabajadores y vehiculos, generalmente son los mismos, pocas veces cambian

Pero puede darse el caso de una alta o baja de algun trabajador, en ese caso seria agregar el nuevo

En el caso de los vehículos, sucede lo mismo, pero además de adicionar, puede darse el caso de que un vehículo cambie la matrícula o el color, en ese caso seria actualizar el dato que cambió

roman
12-09-2014, 16:19:58
Entiendo que la base origen corresponde a un sistema que tú no manejas. Pero aunque no puedes alterar la estructura de las tablas quizá puedes agregar otras para tu propio uso así como algunos triggers. De ser así, podrías implementra disparadores after update, after insert y after delete en las tablas de interés, y con los datos del disparador, insertar registros en una tabla bitácora que te permitan determinar en qué tabla, y qué registros cambiaron.

// Saludos

JoAnCa
12-09-2014, 16:45:42
Entiendo que la base origen corresponde a un sistema que tú no manejas. Pero aunque no puedes alterar la estructura de las tablas quizá puedes agregar otras para tu propio uso así como algunos triggers. De ser así, podrías implementra disparadores after update, after insert y after delete en las tablas de interés, y con los datos del disparador, insertar registros en una tabla bitácora que te permitan determinar en qué tabla, y qué registros cambiaron.
// Saludos

Revisaré para ver si puedo agregarle alguna tabla a la BD :confused:

Otra cosa, nunca he trabajado con los disparadores (triggers), con SQL solo he hecho tablas y vistas, casi siempre lo hago todo en la aplicacion, aunque me he dado cuenta que a veces es mejor "darle mas trabajo a la BD"

Podrias ponerme un ejemplo de como se implementa un triggers?

Por ejemplo, para la tabla vehiculos saber si el campo Matricula se modifico o si se agrego un vehiculo nuevo

roman
12-09-2014, 16:57:09
Yo no puedo darte un ejemplo porque sólo he programado triggers de prueba, nada de lo que me acuerde en estos momentos. Pero sí sé que PostgreSQL maneja triggers y buscando en Google o incluso aquí mismo, seguro que encontrarás algunos ejemplos. No recuerdo que fueran difíciles.

Incluso, recuerdo que alguien alguna vez aquí en el Club, hizo algo bastante bien elaborado precisamente para llevar un control de cambios.

Cosa de buscar. Si encuentro algo, lo enlazo.

// Saludos

JoAnCa
12-09-2014, 17:29:36
Ya estuve consultando a Google y me mostro como es, es verdad es bastante sencillo, lo que pasa es que nunca habia usado triggers :rolleyes:

Hay que crear el trigger y asociarlo a la tabla que quiero controlar el cambio, pero no se si el postgres me dara los permisos para hacerlo :(