Migración de datos con Hibernate

Question

Estoy trabajando en un proyecto para una empresa, donde tengo que migrar sus datos anteriores a un nuevo sistema. Obviamente, ambas estructuras son totalmente diferentes y estoy usando hibernate para la manipulación de la base de datos y estoy confundido en cuanto a cuál sería el mejor enfoque para migrar datos. ¿Debo usar hibernación, debo escribir procedimientos almacenados, o hay otra opción? Cualquier idea brillante es bienvenida.

Answer 1

Aunque no estoy seguro acerca de "lo mejor", preferiría usar Hibernate o un ORM similar si estuviera en su posición. La razón es que entonces tiene una jerarquía de objetos para usar entre las dos bases de datos. Si los esquemas son extremadamente similares, entonces una secuencia de comandos simplemente SQL podría ser más fácil. Realmente depende de cuál es tu situación, y los detalles de la misma.

edición: Realmente necesito un poco de cafeína por la mañana ...

Lo que estaba tratando de hacer notar, fue señalado por las dos personas que se publicaron después de mí. Si los esquemas están definidos, ya tiene objetos o está bien con las herramientas de ingeniería inversa, entonces hibernar es un camino fácil de seguir. Sin embargo, si se trata de algo de una sola vez, los scripts definitivamente son la mejor manera de hacerlo.

Answer 2

Después de haber probado ambos enfoques en el pasado, definitivamente puedo decir que este no es un escenario para el que se diseñó ORM, ni uno donde florece. Terminas teniendo que construir dos conjuntos diferentes de objetos, y es difícil obtener la eficiencia requerida para una migración masiva. La única razón por la que puedo pensar para usar algo como Hibernate sería si estuvieras construyendo un sistema que permanentemente se ubicaría entre dos sistemas para integrarlos, pero parece que esto es relativamente a corto plazo.

He estado muy contento con los resultados de un script python, un grupo de SQL y algunos objetos python para transformar los datos.

Answer 3

Hibernate no funciona muy bien con los procedimientos almacenados, no es un "ajuste natural". Si su ORM ya está planificado y tiene su configuración de objetos 'como está' y 'a ser', use los métodos de hibernación normales para escribir datos en su nuevo diseño.

Si se ve forzado a ir al modo StoredProcedure, puede decidir si quiere tragarse el dolor y codificar sus transformaciones en los procedimientos almacenados, de esa forma todas las secuencias de comandos de migración permanecerán juntas.

Como dijo el otro cartel, un lenguaje de scripting como Python puede servirle bien aquí - me ha funcionado bien también.

Answer 4

Personalmente, probablemente utilizaría una herramienta ETL como SSIS (si va a SQL Server) para esto, el movimiento de grandes cantidades de datos es lo que las herramientas ETl están diseñadas y optimizadas para hacer.

Answer 5

He intentado gestionar la migración de datos cuando cambio mi código y mi representación de datos a través de varias versiones. Cada vez, he terminado escribiendo sql específico para consultar objetos en el estado anterior y llenar nuevas columnas. Si hay una forma sencilla de gestionar la migración de datos mientras se visualiza todo como un objeto, no he pensado en ello, y hasta ahora, las nuevas columnas siempre tienen interpretaciones simples que puedo calcular en sql.

Algunos de ellos han sido lo suficientemente simples para que el código haya terminado en Java, y otros cambios han sido lo suficientemente complejos como para querer varias sentencias SQL, así que terminé incrustándolos en shell y python (ambos, para portabilidad) guiones. Los scripts son here y the java code con nombres de métodos como updateDB2008_4().