Migrar BD de Mysql a PostGreSQL (parte 3)

Conversión de tipos

Resulta, que cuando vemos lo que nos dice el espejo que hemos creado de mysql sobre postgresql con dbi-link, los campos son creados como tipo text, con un comentario en la vista que dice qué tipo de dato aproximado debería haber ahí...

Esto es así, porque los tipos de datos entre diferentes gestores normalmente no son iguales, es decir, todos aplican los estándares, pero además, cada uno le da su toque, de manera que es posible que tenga más o menos, y que de paso, se llamen diferentes... o más bien, se le aplique aliases...

El tema es que cuando trato de leer para insertar en otra tabla, en un proceso de migración, debo tener muy presente los tipos de datos, ocasionalmente, podría recibir un mensaje del tipo:

Error de SQL:

ERROR: la columna «id» es de tipo integer pero la expresión es de tipo text
LINE 1: INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT c...
^
HINT: Necesitará reescribir la expresión o aplicarle una conversión de tipo.

En la declaración:
INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT codcat, codedi, catedi FROM sir_cultura_catedi)

Con lo cual, cualquiera se asusta a la primera... y no hace falta... con leer el mensaje y fijarme en la frase "aplicarle una conversión de tipos" será más que suficiente para tener algo de calma nuevamente...

¿qué es una conversión de tipos? digamos que tenemos un campo de un tipo de dato (p.e. text), pero queremos "interpretar" su contenido como sí fuera otro tipo de dato (p.e. int)... a eso se le conoce como conversión de tipos

INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT codcat::int, codedi::int, catedi FROM sir_cultura_catedi)

o

INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT cast(codcat as int), cast (codedi as int), catedi FROM sir_cultura_catedi)

y listo!!!

Una consultica que tiene algo más:

INSERT INTO cultu04 (reg_001, est_001, mun_001, par_001, cpo_001, cultu04_001, cultu04_002, cultu04_003, cultu04_004, cultu04_005, cultu04_006, cultu04_007, cultu02_001, cultu03_001)
(SELECT codreg, codest, codmun, codpar, codcen, anno, nombre, direccion, telefono, correo, web,
CASE WHEN area <> '' THEN
CAST(area AS numeric)
ELSE
0
END,
codedi::int, codcat::int FROM sir_cultura_edif_det)

Creo que no hace falta explicar la estructura de las tablas, sólo entender que leo en una tabla e inserto lo que estoy leyendo, con algunas particularidades sencillas....

Una más

INSERT INTO acu03 (reg_001, est_001, mun_001, par_001, cpo_001, acu03_001, acu01_001, acu03_003, acu03_004, acu03_005, acu02_001, acu03_006, acu03_007, acu03_008)
(SELECT codreg, codest, codmun, CASE WHEN codpar = 'NA' THEN '00' ELSE codpar END, CASE WHEN codcen = 'NA' THEN '000' ELSE codcen END, EXTRACT(YEAR FROM agno)::int, tipo::int, nb_acueducto, fuentes, caudal, tratamiento::int, suscriptores, poblacion, produccion FROM servicios_acueducto)

Migrar BD de Mysql a PostGreSQL (parte 1 Versión 2)

Diciendo que soy usuario Debian, no digo mucho, pero les cuento que habiendo reinstalado mi equipo de la oficina, en el momento en que estoy devolviendo las cosas a la normalidad, se me ocurrió hacer un aptitude search dbi_link y vaya sorpresa, existe!

Pues, se me ocurrió instalarlo, y probar luego, cómo sería el procedimiento para que funcione... de manera que está sería la versión 2 de Migrar BD de Mysql a PostGreSQL (parte 1)

instalarlo:

• aptitude install dbi_link

buscar donde queda:

• find /usr/ -iname dbi_link

crear la BD en postgresql:

• createdb migracion

crear el lenguaje plperlu a la BD recien creada:

• createlang plperlu -d migracion

lanzar dbi_link.sql a la BD recien creada:

• psql -d migracion -f /path/completo/dbi_link.sql

crear la estructura que me permitirá _conectar_ con la otra BD, en este caso mysql (acá usamos el mysql.sql que viene en el example del dbi_link, que no viene con el aptitude install):

• psql -d migracion -f /path/completo/mysql.sql

y listo! ya está el esquema con la estructura y datos que necesito leer...

Migrar BD de Mysql a PostGreSQL (parte 2)

Después de no sé cuánto tiempo me he decidido a migrar la BD que tengo en mysql a Postgresql. Las razones no son importantes, o más bien es justamente eso, son datos tan importantes que es un crímen tenerlos en mysql...

Para esta demostración voy a utilizar unas tablas básicas que son similares a esto:

CREATE TABLE `Region` (
`codreg` char(2) NOT NULL default '',
`nomreg` varchar(35) NOT NULL default '',
PRIMARY KEY (`codreg`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Tabla de Region';

CREATE TABLE `Estado` (
`codreg` char(2) NOT NULL default '',
`codest` char(2) NOT NULL default '',
`nomest` varchar(35) NOT NULL default '',
PRIMARY KEY (`codreg`,`codest`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Con estas dos tablas se pueden observar ya varios detalles, la utilización de mayúsculas y minúsculas para el nombre de las tablas y la falta de integridad referencial, por otro lado la nueva BD está en utf8 (no es de mi agrado, pero es el acuerdo en que se llegó en la oficina).

Una vez hecho lo escrito en la primera parte de este post he creado un esquema dentro de la misma BD en Postgresql, de manera de leer y copiar en la misma BD, pero en diferentres esquemas. El esquema lo he llamado migracion, donde debo crear las tablas tal y como las necesito, de manera que:

CREATE TABLE region (
codreg character varying(2) NOT NULL,
nomreg character varying(50) NOT NULL
);

ALTER TABLE migracion.region OWNER TO carbonara;

ALTER TABLE ONLY region
ADD CONSTRAINT region_pkey PRIMARY KEY (codreg);

CREATE TABLE estado (
codreg character varying(2) NOT NULL,
codest character varying(2) NOT NULL,
nomest character varying(50) NOT NULL
);

ALTER TABLE ONLY estado
ADD CONSTRAINT estado_pkey PRIMARY KEY (codreg, codest);

ALTER TABLE ONLY estado
ADD CONSTRAINT estado_fkey FOREIGN KEY (codreg) REFERENCES region(codreg) ON UPDATE CASCADE ON DELETE RESTRICT;

Luego, el sql que lee de un lado y escribe del otro:
INSERT INTO migracion.region (codreg, nomreg) SELECT codreg, nomreg FROM "Region";
INSERT INTO migracion.estado (codreg, codest, nomest) SELECT codreg, codest, nomest FROM "Estado"

y listo! Todavía no entiendo por qué me tardé tanto en escribir este post, pero bue...

Migrar BD de Mysql a PostGreSQL (parte 1)

El escenario: una BD en mysql que hay que migrar a postgresql, tomando en cuenta que hay sistemas que están utilizando ambos motores al mismo tiempo.

Temporalmente, se estableció una conexión con dbi-link. La documentación es más o menos sencilla, sólo hay que retocar el escript que corresponda al motor a conectar, en mi caso, mysql. En la carpeta examples, consigimos para conectar entre otros, oracle, mssql, mysql.

Los pasos, son más o menos así:

1. crear el lenguaje plperl para la BD: create language plperlu;
2. lanzas dbi_link.sql ( te crea el esquema y las funciones necesarias), en mi caso, lo hice con psql <>
3. Conectar con la BD, igual, psql <>

Con esto me ha funcionado, de manera que ya puedo ver 2 esquemas adicionales en mi BD, uno creado por dbi_link.sql, y otro que le he puesto de nombre mysql (ya que estoy conectando con mysql) donde están todas las tablas con una estructura que me permite leer los datos, justo lo que necesitaba. Vale decir, que los datos no se están copiando, sino que se ven como en tiempo de replicación.

Esto lo logré con algo de ayuda, además de la documentación, de parte del amigo seyko, que se puede ver en http://www.forosdelweb.com/f21/reporte-almacen-con-datos-postgresql-mysql-536140/#post2201060.

En los próximos minutos/horas/días/semanas/meses espero publicar la segunda parte, donde copiaremos datos de mysql a postgresql.

Para los usuarios de Debian y derivados, que prefieren aptitude, acá una forma muy parecida de hacerlo