Migrando y procesando datos

La migración esa tarea que puede ser muy tediosa dependiendo el cómo está la información origen, desde mi punto de vista es un odio/amor, por llamarlo de alguna manera, que es muy satisfactorio el cómo los datos se van procesando y reorganizando, pero también se convierte en lo más odiado cuando la información está mal pero muy mal organizada.

En este caso me refiero a la migración de un motor bd a otro (ejemplo: Access a mysql, mysql a postgressl) y claro con una nueva estructura.

MySQL WorkbenchEn las migraciones que he realizado me gusta usar PHP por su simplicidad para poder realizar esta tarea, independientemente del lenguaje que usara el nuevo sistema, pero bueno creo que este dato es irrelevante, porque con el que más nos acomodemos funcionara bien.

En las migraciones no es primordial conocer cuántos registros faltan, o cuantos nos sobraron (depende de su código de migración esto puede llegar  pasar), lo más importante es conocer que registros están faltando, y sobre todo porque están faltando. De esta manera podremos lograremos migrar el 100% de la información a la nueva BD.

En ocasiones pueden pasar días antes de probar que nuestro código funciona como debería, ya que cuando lo estamos desarrollando solo podemos imaginar el como la información se ira procesando, que podremos ir validando, en estos códigos es cuando más hay que cuidar que sea lo más óptimo posible y evitar consultas innecesarias a la base de datos, ya que si pensamos en que solo se usara una vez, esto nos podrá traer mucho tiempo perdido, porque si estamos hablando de megas o gigas de información a procesar entonces la migración podrá tardar horas (muchas).

MySQL Workbench_3Pero sorpresa, este código no se ejecutara una sola vez, y no estoy hablando que haya más bases de datos idénticas que migrar, me refiero al echo que durante el periodo de desarrollo y pruebas será necesario ejecutar tantas veces como sea necesario el código de migración, por consiguiente cualquier tarea manual que piensen hacer para procesar la información queda totalmente descartada, porque la migración debe llevarse a cabo,  aunque no se encuentre la persona que desarrollo dicho código.

Es por ello que aunque esto se vaya a usar solo durante el desarrollo del sistema, no debemos menos preciarlo ya que entre más rápido trabaje más rápido podremos hacer pruebas, no creo que te guste decir, “ok pero esperen 8 horas para poder iniciar con las pruebas”.

Pero espera, no tan rápido que las cosas no son tan simples como parecen, de echo antes que puedas decir “Ya tengo el código de migración”, es probable que te topes con muchos problemas por ejemplo, cuando terminaste tu código, y empiezas a probarlo comprobaras como de la nada empiezan a aparecer errores, tal vez porque en la anterior base de datos, la información no se validó correctamente, hay caracteres especiales que no pensaste que estaban allí, o la información no está en el formato que debería, por ejemplo si el código de algo era: T/123456  ahora te das cuenta que también hay T123456 e incluso X1234, cuando este último ni siquiera tiene razón de ser y te preguntaras “cómo es posible que se esté guardando este dato de esta manera!”

MySQL Workbench_4Por lo anterior es que te recomiendo invertir en tu código para que te lleve un  registro  de los errores y del porqué, con la finalidad que cuando termines de correr el o los script deberás encontrarte con ese registro en blanco y es cuando por fin has logrado el 100% de la migración.

Por ultimo evita códigos que te hagan estas pegado a la computadora hasta que termine la migración (dando y dando clic), te recomiendo trabajar un poco de más, para que cuando ejecutes dicha migración esta no se detenga hasta que termine (recuerda que ya funciona), y agrega una barra de progreso o algo para que sabes cuánto falta y sea menos estresante la espera.

 

En mi última migración el código tardaba cerca de dos horas, por lo cual decidí hacer cambios a la bd cambiando en algunas tablas el motor de almacenamiento y otras características, una vez terminada la migración regresaba está a su forma original (de echo el código se encarga de hacer esto jeje) pero es muy satisfactorio dar solo clic y que los datos aparezcan ya reorganizados, aunque es muy común que no se pueda migrar toda, esto dependiendo el origen, pero si ya no es posible esto, debemos tener un reporte de que datos faltan para tomar una decisión, ya en otras migraciones y teniendo practica podremos pasar de 6 horas a solo 2 por ejemplo, lo que quiero dar a entender es siempre buscar lo más óptimo.

migrando

 

Leave a Reply

Your email address will not be published. Required fields are marked *