Migrando de MSQL a MySQL: Movida arriesgada
Jorge Camargo me mandó el siguiente correo:
Y yo ni corto ni perezoso le respondo a Jorge :DMira esta experiencia José Migrar de SQL Server a MySQL
http://www.fernandoplaza.com/2005/08/migrar-de-sql-server-mysql.asp
has hecho algo parecido? seria bueno comentar algo en tu blog ;o)
Saludos
JC
La verdad es que nunca he hecho nada parecido; Lo más cercano que intenté alguna vez fué migrar de Sybase a PostgreSQL en mi compañia anterior y eso fué porqué los precios simplemente nos estaban matando. Sin embargo (y que me perdone Jorge) recuerdo que decidimos usar PostgreSQL en vez de MySQL debido a que MySQL no soportaba "stored procedures" y el sistema que pensabamos migrar los utilizaba mucho dado la enorme cantidad de información de Bonos que procesabamamos (El proyecto, "FACTORS", tenía información de agencias como FNMA, GNMA y Freddie Mac, más de 50GB y creciendo).
Uno de los mitos de las bases de datos comerciales en Linux es que no se desempeñan bien; En el caso de Sybase, su rendimiento era muy bueno (después de entonado, claro está). Al final, recuerdo que con PostgreSQL nos acercamos bastante al rendimiento de Sybase, lo cual me lleva a recordar (a groso modo) que consideramos para la migración:
- Rendimiento: Si no se desempeña igual de rápido que la BD comercial, (ni siquiera particionando los datos) entonces ni lo intente
- Compatibilidad: Si utiliza puro software de Windows (ODBC por ejemplo) entonces quizas es muy complicado; Por otro lado MySQL y PosgreSQL cuentan con excelente soporte de manejadores para Perl (DBI, DBD::MySQL, DBD::PosgreSQL), Java (JDBC), Python, etc.
- Stored Procedures: No sólo debe soportarlos, sino que la sintaxis debe ser similar, para poder migrar el código existente. Por ejemplo, Sybase y Microsoft utilizan "Transact/SQL" (Microsoft compró la tecnología de Sybase años atrás), mientras que Oracle utiliza "PL/SQL". PostgreSQL utiliza algo muy parecido a PL/SQL pero en el caso de mi migración yo tuve que lidiar con problemas de la nueva sintaxis, limitaciones de el lenguaje, tipos de datos (ojo PostgreSQL no es inferior a Sybase, es simplemente que son distintos).
- Diferencias: Como lo mencioné antes, cada equipo deberá aprender las diferencias de la nueva herramienta. Hay mucha documentación y soporte para las BD OpenSource, pero igual la curva de aprendizaje es inevitable.
- Soporte: Hay compañias prestando soporte a ambas bases de datos. Pero si usted tiene un contrato entonces por ¿cuanto tiempo deberá mantener viva la vieja BD, antes de estar seguro que no hay que regresar la migración?. Yendo más lejos, yo en este momento estoy migrando una aplicación web de MySQL a IBM DB2; La razón es soporte interno, ya que la compañia no tiene un equipo ni hardware dedicado de soporte dedicado a esta entonces ese trabajo nos queda a nosotros. Nosotros estamos en esa unidad de negocios para hacer dinero, no soportar bases de datos así que la decisión es obvia (curiosamente ya existía Sybase bajo Linux cuando se comenzó la aplicación pero el costo de las licencias era elevado para la unidad de negocios). Aqui el costo oculto de MySQL es que hay que entrenar a los DBA de la compañia para soportar otra BD.
Y usted, ¿tiene alguna historia
Buscar en Technorati: mysql
escrito por KodeGeek @ 4:39 AM (enlace permanente)
5 Comentarios:
pues yo estoy en una empresa del gobierno y por el decreto 3390 estamos migrando a software libre, es poca la informacion que podemos migrar de una vez (por no decir nada), ya que la mayoria de software esta en visual basic y fox pro,uno que otro en sql server (windows) y los ultimos 5 sistemas en php, pero gracias a q no existe una base de datos total sino muchas islas de informacion separa se esta practicamente decidiendo el borrar todo y empezar desde 0 (si vieran los codigos entenderian), pero la migracion de los sistemas php a postgresql (estabn en mysql, nos fuimos a postgresql por los procedures) fue trasparente, solucion? PEAR:DB es muy parecido al DBI de pearl pero para php deberian de probarlo
Jimmy
Hola José,
Bueno creo que en la nueva versión de MySQL, la 5.0 va a soportar lo de store procedures;
http://dev.mysql.com/tech-resources/articles/mysql-storedprocedures.html
En mis trabajos anteriores mis funciones con bases de datos no han sido muchas por lo que no tengo experiencia con la migración de datos, por eso te pregunté ;o)
y bueno no me enojo por tu comentario jeje ni mas faltaba pero si reconozco que debería conocer más bases de datos como postgres.
Saludos
JC
Hola Jorge, no lo decía por fastidiar; De hecho la escogencia de una base de datos es casi un aspecto religioso, dado lo competivias que son con las opciones (o más bien diria yo lo poco que se diferencian entre ellas).
Si necesitas algo rapido, sin mucho problemita para aplicaciones que vayan a requerir una carga muy pesada y necesiten un tiempo de respuesta casi critico (en fin, si vas a hacer un sitio web de alto trafico) recomiendo MySQL. El problema es que todo el procesamiento tienes que dejarlo a nivel de codigo y usar las sentencias SQL solo para traerte datos.
Si necesitas hacer una aplicacion empresarial donde lo que mas importa es la robustez, sacrificando solo un poco el tiempo de respuesta y obteniendo beneficios como procedimientos almacenados, manejo de transacciones y triggers lo recomendable es PostgreSQL.
Es mi punto de vista, de esa forma lo eligiria yo.
Ah.. y con respecto a la forma de conectarse a las bases de datos, si es con PHP, les recomiendo una libreria llamada ADOdb, pero no la de windows sino la de PHP: http://adodb.sf.net
Saluts.
En la vida real, de la consultoría informática, se saben tres cosas con respecto a un único concepto.
Migrar = Problemas graves de reconversión e implantación.
Migrar = Proyecto largo y con mucho dinero detrás, dependiendo de cómo se cerró el negocio.
Migrar = Multa por retraso de proyecto, también dependiendo de cómo se cerró el negocio.
Publicar un comentario en la entrada
Enlaces a este articulo:
Crear un enlace
<< Regresar