[l-desarrollo] Sugerencias con procesos de cargas de archivos planos que ocasionarán inserciones actualizaciones y borrados en base de datos postgres
Alfredo Rico
Debo desarrollar unos procesos de carga de archivos planos a tablas postgres.
Pongo este caso:
Tenemos una tabla para el maestro de clientes. Cada día vendrá un
nuevo archivo plano conteniendo el maestro completo de clientes. Pero
puede suceder que en dicho archivo sucedan algunos de los siguientes
casos:
Vienen los mismos clientes. (no pasa nada)
Vienen nuevos clientes (nuevas inserciones)
Vienen clientes con datos actualizados modificados.
Vienen clientes con identificador único modificado (que hacer con los
anteriores, cómo detectarlos sin afectar el rendimiento del
procedimiento)
No vienen clientes (por lo tanto eliminación).
Planteo la creación de tablas "stage" que siempre se truncan y sobre
la cual se vacian diariamente con un copy los archivos planos.
Planteo la creación de procedimientos almacenados con consultas para
las diferencias y setencias DML entre la tabla stage y tabla destino.
Sin embargo quisiera saber si han tenido experiencia al respecto y si
me pueden recomendar algunas buenas prácticas para llevar a cabo esta
tarea.
Muy agradecido.
--
Saludos Cordiales.-
Alfredo Rico.
San Cristóbal - Venezuela.
_______________________________________________
l-desarrollo mailing list
l-desa...@velug.org.ve
http://listas.velug.org.ve/mailman/listinfo/l-desarrollo
Alejandro Imass
> Buen día amigos, reciban un cordial saludo.
>
> Debo desarrollar unos procesos de carga de archivos planos a tablas postgres.
> Pongo este caso:
> Tenemos una tabla para el maestro de clientes. Cada día vendrá un
> nuevo archivo plano conteniendo el maestro completo de clientes. Pero
> Planteo la creación de tablas "stage" que siempre se truncan y sobre
> la cual se vacian diariamente con un copy los archivos planos.
[...]
Si es muy común el uso de tablas intermedias. El mayor problema es
mantener la integridad referencial, de hecho, es una aplicación típica
de los llamados "surrogate keys"[1]. En tu maestro de clientes _nunca_
vas a eliminar datos ya que seguramente poseen transacciones que han
creado dependencias de integridad referencial con otras tablas, e.g.
facturas.
Tanto la tabla intermedia como la del maestro como tal tienen uno o
varios campos que conforman el surrogate key (una llave lógica o de
aplicación), pero el mastero tiene un primary key, generalmente un
simple entero serial (o autokey). El primary key NUNCA cambia y los
registros nunca se eliminan sino que mas bién puedes manejar otro
campo para eliminarlos lógicamente ('obsolete', 'deleted', 'inactivo',
etc.)
La integración entre la tabla temporal y la activa (a.k.a. current
database) se hace a través del surrogate key. Por ejemplo, para un
maestro de clientes puede ser el RIF, para inventario puede ser el
número de parte, para personas la cédula, etc. Fíjate que el modelo de
surrogate key te permite incluso cambiar el surrogate key, sin romper
la integridad referencial con registros pre-existentes, ya que ésta se
mantiene por el primary key real (un simple número entero). A veces la
integración entre las tablas temporales y las corrientes no es tan
sencilla y depende de varios campos, ya que el surrogate key puede no
ser tan claro, o puede ser la combinación de varios campos. E.g. en
USA es muy común utilizar nombre1 + apellido1 + fecha de nacimiento
como surrogate key para identificar personas, ya que no existe el
concepto de cedulación.
[1] http://en.wikipedia.org/wiki/Surrogate_key
Saludos,
--
Alejandro Imass