Cita:
Empezado por Lepe
Aconsejo normalizar las tablas, crear el mismo campo en dos tablas que se relacionen, pero no uses el "foreign key" al definir las tablas. Te obliga a escribir 2 sqls al actualizar, borrar una tabla detalle y después la maestra, pero no es nada con el lío de "foreigns keys", te lo garantizo.
Saludos!
|
No entiendo esto. Anular los chequeos de integridad solo hace que sea mas dificil (o imposible) darse cuenta si algo salio mal. De eso vivi muchos problemas cuando usaba tablas de dbase y aun no tenian esos chequeos.
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)