Migración de un DBMS a otro [cerrado]

Question

¿Alguien tiene alguna experiencia migrando de un DBMS a otro? Si has hecho esto, ¿por qué lo hiciste? ¿Caracteristicas? ¿Costo? Directiva corporativa?

A veces, he trabajado con DBA que insistieron en que no usáramos características específicas de un DBMS (por ejemplo, procedimientos almacenados CLR en SQL Server). El punto de DBA es que, si usamos estas características, lo hará Es más difícil cambiar a otro DBMS si es necesario. Pero hasta ahora, nunca me han pedido que cambie.

Answer 1

En mi opinión, es una tontería no aprovechar todas las características de la base de datos que está utilizando. Cambiar el DBMS independientemente de cuántas funciones use será difícil. Existen diferencias mínimas entre los sistemas (como algunas fechas de registro y alguna fecha y hora de registro) que causarán un gran dolor de cabeza para cambiar. No existe el simple hecho de cambiar a un nuevo dbms.

Desde una perspectiva empresarial, hay mucho trabajo por hacer. Análisis sobre los nuevos dbs a los que cambiar. Averiguar el impacto de cambiar dbs en el nuevo sistema. Hacer que el desarrollo cambie los sistemas existentes, probar los cambios, etc. La lista sigue y sigue. Hacer un cambio así en un sistema empresarial lleva meses, si no años. El último lugar donde trabajé tuvo que cambiar dbs, y nos tomó unos sólidos 11 meses hacerlo y alrededor de 2 millones de dólares para consultores, hardware, software y salarios de empleados. Tiene mucha importancia. Si alguien está diciendo que no use las funciones, porque eso "puede" ocurrirá algún día y será más fácil de hacer, lo más probable es que esa persona esté fuera de su eje de balancín. La cantidad adicional de tiempo y dinero que se necesitará para convertir esas características es minúscula en comparación con todo lo demás (muy probablemente). En mi opinión, si ahorrará tiempo y dinero ahora compre usando esas características, entonces ese es el mejor curso de acción.

Lo hicimos porque los sistemas que teníamos en el viejo dbms eran demasiado grandes. Había demasiados datos y necesitábamos algo mucho más poderoso. Además, ya no era compatible.

Answer 2

Trabajé en una empresa durante varios años, cuyo producto era compatible con Oracle o SQL Server. Mantuvimos el modelo en Erwin y generamos scripts de esquema, disparadores y paquetes de Oracle a partir de él. Los paquetes se usaron para hacer que los activadores de Oracle funcionen de manera similar a los de SQL Server (con tablas lógicas 'insertadas' y 'eliminadas'). Conservamos dos conjuntos de secuencias de comandos de procedimientos almacenados.

Con ese desastre en mi haber, sugiero que pueda migrar grandes proyectos, siempre que pueda hacer que su nivel de datos se separe por completo de cualquier código lógico. Si puede hacer eso, puede implementar las características de la base de datos que acelerarán la aplicación en el nivel de datos, sin afectar su aplicación principal.

Answer 3

Cambiado muchas veces. Principalmente porque la "Conversión involuntaria" - un producto antiguo ya no es compatible o ya no es adecuado.

• DB2 a Oracle. Los datos anteriores a UDB se conservaron y se trasladaron a Oracle.
• Acceso MS a Oracle. Continúo usando el front-end de Access sobre las tablas de Oracle.
• Oracle a Oracle. 6 a 8, creo ...

" ¿por qué lo hiciste? '' No características. Sin costo En todos los casos, algo está roto.

• El producto viejo ya no funciona. Una actualización del sistema operativo o algo más ha hecho que el producto heredado se rompa.
• El producto antiguo no escalaba.

Cambiar rara vez es algo que eliges hacer. Se le impone cuando los proveedores cierran (Ingres hizo esto una vez) o deja de admitir su versión (Microsoft lo hace con frecuencia).

Entonces, por supuesto, es una crisis. Compuesto por la complejidad técnica de los cambios en el disparador y el procedimiento almacenado. Si solo fueran los datos, no sería una gran crisis. Vuelva a alguna forma estándar (CSV, por ejemplo), vuelva a cargar y estará en funcionamiento.

Más importante aún, cuanto más '' cosas '' (procedimientos almacenados, disparadores, etc.) en la base de datos, cuanto más se convierta su software de aplicación en una pila confusa de errores difíciles de seguir (y difíciles de mantener). No hay nada tan frustrante como esperar semanas para que alguien rastree el nombre de un procedimiento almacenado. Si se tratara de un código VB, todos tendrían acceso a él. Pero como estaba en la base de datos, se volvió, paradójicamente, menos visible. El código es código y debe mantenerse alejado de los datos.

Consulte ¿Dónde colocar su código - Base de datos vs. Aplicación? para obtener más información sobre este tema.

Answer 4

He estado involucrado en varios proyectos para migrar datos de una base de datos a otra. En todos los casos, se estaban migrando los datos, no el RDMBS. Si una aplicación está funcionando, no habrá ninguna presión para cambiar las bases de datos por el simple hecho de cambiar. El ímpetu para la migración generalmente se debe a que los datos del sistema antiguo están desactualizados, son incompatibles o ambos, y eso también brinda la oportunidad de cambiar el RDBMS.

El cambio más probable es consolidar los datos de referencia (empleados, clientes, etc.) en la base de datos maestra existente (por consistencia y facilidad de uso) y luego modificar todas las otras tablas para que las claves apunten a Nuevos datos de referencia. Esto requiere un esquema y los cambios de código correspondientes arriba y abajo de la pila. Es una migración de datos, no una migración de base de datos. Y lo más probable es que desee aprovechar la oportunidad de agregar datos, estandarizar nombres o (des) normalizar las tablas, etc.

El resultado es que estos proyectos casi siempre tienen un enorme impacto en los datos, el esquema y el código, y cualquier trabajo necesario para, por ejemplo, traducir T-SQL a PL-SQL será una parte trivialmente pequeña del proyecto. Entonces, si está pagando por un buen RDBMS, úselo todo. Hacer lo contrario sería como no usar la cajuela o la guantera de su automóvil nuevo para que sea más fácil cambiar de automóvil cuando compre uno nuevo.

Answer 5

Otro punto (en apoyo de S.Lott). Dependiendo de su entorno de desarrollo, es posible que a sus desarrolladores no les resulte fácil desarrollar o incluso ver procedimientos almacenados. Dividir el código de su aplicación entre dos conjuntos diferentes de herramientas de desarrollo y entornos de ejecución puede ser complicado y puede dificultar la búsqueda de empleados calificados.

No creo que sea un argumento en contra de los procedimientos almacenados, pero ciertamente es algo a considerar al decidir dónde debe residir el código para un componente dado de sus aplicaciones.

Answer 6

Lo hicimos una migración de HP3000 a Oracle. Nos costó 25 millones de dólares y también agregó el costo de perder 200 millones de dólares en datos debido a tal maldita prisa que no pensaron en lo que estaban haciendo. También he encontrado muchos lugares que solo lo ven como un movimiento. Descubrirán el resto más tarde ... mucho más tarde.