Artículo
· 4 hr atrás Lectura de 4 min

Consideraciones al migrar de Oracle, MSSQL, etc. a IRIS

Migrar desde Oracle, MSSQL u otros sistemas de bases de datos puramente relacionales a un sistema multimodelo como InterSystems IRIS es una decisión estratégica que requiere una planificación y ejecución cuidadosas. Aunque esta transición ofrece beneficios significativos, como un mejor rendimiento, escalabilidad y soporte para arquitecturas modernas, también conlleva desafíos. En este artículo destacaré algunas de las consideraciones relacionadas con la codificación para asegurar una migración exitosa. Dejaré fuera del alcance de este artículo todo lo relacionado con la migración real de estructuras y datos.

Primero, cuando estáis considerando migrar a un sistema de base de datos diferente, necesitáis comprender vuestra lógica de negocio, ya sea del lado de la aplicación (servidor de aplicaciones) o del servidor de bases de datos. Básicamente, ¿dónde tenéis vuestras sentencias SQL que potencialmente tendréis que reescribir?

Cuando vuestra lógica de aplicación depende en gran medida de SQL ejecutado directamente dentro del código de la aplicación (en lugar de procedimientos almacenados o triggers en la base de datos), migrar desde una base de datos relacional a InterSystems IRIS requiere un examen cuidadoso de vuestras sentencias SQL. Veamos algunos de los factores más importantes que debéis tener en cuenta.

  1. Diferencias en el dialecto SQL. SQL de IRIS admite el estándar SQL-92. Esto no significa que no estén implementadas algunas funcionalidades más modernas. Simplemente significa que necesitáis comprobarlo de antemano. Por ejemplo, las funciones de ventana aparecieron en SQL:2003, pero aún así podéis escribirlas en IRIS.
--window function
select id, rating
  from (select a.id, 
               r.rating, 
               avg(r.rating) over () as avg_rating 
          from SQLUSER.Actor a join SQLUser.Review r on a.id = r.Reviews) as sub 
 where rating > avg_rating

Al mismo tiempo, los nuevos tipos de datos complejos, como XML, JSON, Arrays y tipos de datos geográficos, no están soportados. Así que la siguiente consulta:

SELECT a.id, 
       a.firstname, 
       ARRAY_AGG(r.rating) AS ratings 
  FROM SQLUSER.Actor a LEFT JOIN SQLUser.Review r ON a.id = r.Reviews 
GROUP BY  a.firstname

devolverá un error: ERROR #5540: SQLCODE: -359 Message: User defined SQL function 'SQLUSER.ARRAY_AGG' does not exist

Pero no es el fin del mundo. Hay muchas funciones integradas que os permitirán reescribir las consultas para obtener el resultado esperado.

2. Funciones integradas. Los distintos sistemas de gestión de bases de datos tienen diferentes funciones integradas. Por lo tanto, necesitáis comprender cómo se corresponden con las disponibles en IRIS. Aquí tenéis varios ejemplos de lo que os estoy comentando: funciones usadas en Oracle y sus equivalentes en IRIS.

Oracle IRIS
NVL ISNULL(field, default_value)
substr $extract(field, start_pos, end_pos)
instr $find(field, text_to_find)
concat {fn CONCAT(string1,string2)}

Cuando vuestra lógica SQL principal reside dentro de la base de datos (por ejemplo, procedimientos almacenados, triggers, vistas), migrar a InterSystems IRIS requiere un enfoque diferente. Aquí tenéis algunas consideraciones:

  1. Migración de objetos de base de datos
    1. Todos los procedimientos almacenados deben reescribirse usando ObjectScript. Esta también puede ser una buena oportunidad para cambiar al modelo orientado a objetos, ya que obtendréis una tabla igualmente al crear una clase. Sin embargo, trabajar con clases os permitirá escribir métodos (que pueden llamarse como procedimientos almacenados) y usar todo el potencial del paradigma orientado a objetos.
    2. Los triggers, índices y vistas están todos soportados por IRIS. Incluso podéis dejar las vistas tal como están si las columnas de las tablas se mantienen iguales y no utilizan funciones o sintaxis no soportadas (ved el punto anterior).
  2. La migración de definiciones también es importante y puede presentar algunos desafíos. Primero, debéis hacer una correspondencia cuidadosa de los tipos de datos de vuestra base de datos anterior con los de IRIS, especialmente si estáis usando tipos de datos complejos. Además, al tener más flexibilidad con los índices, quizás queráis redefinirlos de forma distinta.

Aquí tenéis algunas cosas que debéis considerar al decidir migrar a InterSystems IRIS desde otra base de datos relacional. Es una decisión estratégica que puede desbloquear beneficios significativos, incluyendo una mayor escalabilidad, rendimiento y eficiencia. Sin embargo, una planificación cuidadosa es crucial para asegurar una transición fluida y abordar necesidades de compatibilidad, transformación de datos y refactorización de la aplicación.

Comentarios (0)1
Inicie sesión o regístrese para continuar