Levantando una base .mdf y hacer un espejo

[Chema Cortes]

El 2006/11/22, Diego Levental <dlevental en gmail.com> escribió:
> Hola gente, quiero hacer un scripcito de la mejor manera posible.
> Necesito que me tome una base "cliente.mdf" ,  busque alguna modificaciones
> en sus campos y actualice esos datos en otra base mysql. (espejo)
>
> La mejor manera de hacer esto seria:
> 1) Levantar todos los días la base completa? Si, es así , cuanto puede
> tardar este procesito ?
> 2) Algún algoritmo que verifique las tuplas y en caso de encontrar una
> diferencia...update?
>
> Dato: La base tiene 15.000 clientes y en crecimiento. (1000 anual aprox.) X
> 20 columnas aproximadamente

No te creas que con esta información podemos ya hacernos idea del
tamaño de la base de datos. Si en realidad estás hablando de 15.000
registros, uno por cliente, se trata de una tabla realmente pequeña y
su traspaso sería rapidísimo.

En cuanto a algoritmos que detecten cambios, lo mejor es que borres
todo y lo vuelvas a cargar entero. Yo hago algo así con cargas diarias
de nóminas de 50.000 trabajadores con alta rotación de puestos de
trabajo, fluyendo los datos desde informix --> postgresql --> oracle.
Los gestores de bases de datos no tienen excesivos problemas con los
vaciados masivos, bastando pasar un proceso de optimización con alguna
frecuencia (eg: VACUUM de postgresql). Si quieres algo más fino,
tendrías que incluir en el sqlserver un trigger que marque los
registros modificados, con un cuidado exquisito si permites que la
clave principal pueda cambiar para que no se dupliquen clientes.
Demasiado trabajo para tan pocos registros.


> Se me ocurre que se podría hacer algo reutilizable....es decir , definir las
> columnas de la base (tipo model.py de turbogears) y darle la ruta de la .mdf
> y que haga el update. De esta manera sincronizaríamos las 2 bases

En el caso que contaba antes, utilizo una tabla de postgresql para
parametrizar el proceso. Básicamente, le paso la consulta sql a
realizar en cada servidor de informix y una sentencia de inserción en
postgres de los datos obtenidos, tabla que coincide en estructura con
la tabla final de oracle.

Trabajando con SQL directamente me permite utilizar "alias" con lo que
encajar mejor una estructura en otra, además de poder limitar mis
búsquedas a periodos temporales determinados. En mi opinión, lo de
crear "modelos" de datos está bien para definir los requisitos de un
desarrollo que empieza de cero; pero no tiene tanto sentido si vas a
usar bases de datos que ya estaban en explotación. Al final acabas por
crear vistas o tablas secundarias para desacoplar el "modelo" de datos
de la evolución real de tu base de datos.