FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#8
|
||||
|
||||
Cita:
Si los tiros van por desnormalizar los datos que se envian para sincronizar y re-aplicarlos en un esquema local (que si tiene todos los check activos) eso esta bien. Ahora, el lio que planteas (maestros, detalles, relaciones) es el problema de la sincronizacion, pero es un problema que se resuelve usando EXACTAMENTE lo mismo que usan las BD para mantener su salud antes las fallas, el LOG. Este articulo es altamente esclarecedor: https://engineering.linkedin.com/dis...datas-unifying Ahora todo esto lo llaman EVENT SOURCING: http://martinfowler.com/eaaDev/EventSourcing.html ---- Sincronizar una tabla es facil, pero como se hace cuando son relaciones y demas? El truco es entender que estamos hablando de como los datos se mueven en el TIEMPO. Asi, que si se hace un intento ingenuo de usar TIMESTAMPS o campos VERSION va a ser muy dificil porque esos campos carecen de la informacion para reconstruir como se movio no solo el REGISTRO, sino el conjunto de ellos entre todas las tablas. Asi que lo que hay que hacer para hacer un sync robusto y no perder ninguna de las ventajas del modelo relacional, es hacer un LOG! Ej: 1- INSERTADO: Encabezado = 1 WITH Data(.......) 2- CAMBIADO: Encabezado = 1 WITH .... 3- INSERTADO: Detalle = 1 WITH .... 4- INSERTADO: Detalle = 2 WITH .... 5- BORRADO: Detalle = 1 WITH .... Noten como el log captura de forma NATURAL el orden de los pasos. Asi que solo hay que leer el log para recuperar el estado de los registros. NO IMPORTA SI LEES EL LOG PARCIAL, mientras allas empezado desde el principio y sigas de forma secuencial, puedes parar en CUALQUIER momento, y continuar despues y al final tendras una lectura consistente. Este log es LOGICO. De hecho, es mejor hacerlo usando lenguaje de negocios: 1- CREADA.FACTURA con DATOS = 1- CAMBIADA.FACTURA con DATOS = 1- CREADA.DETALLE... Noten, es IMPORTANTE: Siempre se hace log sobre lo que ocurrio en EL PASADO. Por lo tanto, es despues de haber hecho todas las validaciones, y de haber asignado los datos en la tabla(s) de destino. De esta forma, se garantiza que cada linea representa un hecho consistente y confiable, y que si se borran TODOS los registros de la BD, se puede usar solamente el LOG y al final tendras la misma info de antes. EXACTAMENTE como hacen los motores para manejar sus transacciones, sus backups, replicarse y demas. EXACTAMENTE como el modelo contable: SI has registrado correctamente todos los asientos, se debe poder re-construir TODOS LOS DOCUMENTOS en base a esto. (Eso es lo que en la antiguedad hacia la opcion de "Reconstruir los datos" que usaban los programas de facturas hechos en DOS. Como los engine eran poco confiables y sin FOREIGN KEYS, transacciones, CHECK y demas mejoras que trajeron las BD modernas, los datos se desincronizaban y/o perdian, asi que tocaba recurrir al diario de transacciones para reconstruir los datos)
__________________
El malabarista. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
como realizar actualizacion con exists en firebird | uper | Firebird e Interbase | 6 | 24-11-2014 16:44:01 |
Sugerencias para realizar una actualizacion de un registro en Firebird | agustinbus | Firebird e Interbase | 18 | 14-03-2012 23:39:00 |
Distribuir una Aplicacion creada con Delphi 2007 y Firebird. | Adrian Murua | Firebird e Interbase | 2 | 18-05-2008 16:13:01 |
Crear Backup solo de algunas tablas de mi bas de datos de SQL | jooooseph | Conexión con bases de datos | 0 | 18-10-2007 22:27:47 |
Como agilizar actualizacion de tablas desde la red utilizando delphi, sql, dbaseIV | Silviña | Conexión con bases de datos | 3 | 19-05-2004 17:23:10 |
|