Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   PostgreSQL (https://www.clubdelphi.com/foros/forumdisplay.php?f=42)
-   -   Como sincronizar dos Bases de Datos (SQLite y PostgreSQL) (https://www.clubdelphi.com/foros/showthread.php?t=86613)

JoAnCa 08-09-2014 20:02:22

Como sincronizar dos Bases de Datos (SQLite y PostgreSQL)
 
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

Cita:

Empezado por Casimiro Notevi (Mensaje 480926)
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

Cita:

Empezado por JoAnCa (Mensaje 481049)
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

Cita:

Empezado por roman (Mensaje 481284)
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 :(


La franja horaria es GMT +2. Ahora son las 15:47:52.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi