Considerações ao migrar de Oracle, MSSQL etc para o IRIS

Migrar de Oracle, MSSQL ou outros sistemas de banco de dados puramente relacionais para um InterSystems IRIS multimodel é uma decisão estratégica que requer planejamento e execução cuidadosos. Embora essa transição ofereça benefícios significativos, incluindo desempenho aprimorado, escalabilidade e suporte para arquiteturas modernas, ela também apresenta desafios. Neste artigo, destacarei algumas das considerações relacionadas à codificação para garantir uma migração bem-sucedida. Deixarei tudo o que está conectado a uma migração real de estruturas e dados fora do escopo deste artigo.

Primeiramente, ao considerar migrar para um sistema de banco de dados diferente, você precisa entender sua lógica de negócios, seja ela do lado da aplicação (servidor de aplicação) ou do servidor de banco de dados. Basicamente, onde você tem suas instruções SQL que potencialmente precisará reescrever?

Quando a lógica da sua aplicação depende fortemente de SQL executado diretamente no código da aplicação (em vez de dentro de stored procedures ou triggers no banco de dados), migrar de um banco de dados relacional para o InterSystems IRIS requer um exame cuidadoso das suas instruções SQL. Vamos analisar alguns dos fatores mais importantes nos quais você precisa pensar.

1. Diferenças de dialeto SQL. O IRIS SQL oferece suporte ao padrão SQL-92. Isso não significa que alguns recursos mais modernos não estejam implementados. Significa apenas que você precisa verificar previamente. Por exemplo, as funções de janela apareceram no SQL:2003, mas você ainda pode escrevê-las no 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

Ao mesmo tempo, novos tipos de dados complexos, como XML, JSON, Arrays e tipos de dados geográficos, não são suportados. Então, a seguinte 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

retornará um erro: ERROR #5540: SQLCODE: -359 Message: User defined SQL function 'SQLUSER.ARRAY_AGG' does not exist

Mas não é o fim do mundo. Existem muitas funções integradas que permitirão que você reescreva as consultas para obter o resultado esperado.

2. Funções integradas. Diferentes SGBDs (Sistemas de Gerenciamento de Banco de Dados) possuem diferentes funções integradas. Portanto, você precisa entender como elas correspondem às disponíveis no IRIS. Aqui estão vários exemplos do que estou falando, funções usadas no Oracle e seus equivalentes no IRIS:

Quando sua lógica SQL primária reside dentro de um banco de dados (por exemplo, stored procedures, triggers, views), migrar para o InterSystems IRIS requer uma abordagem diferente. Aqui estão algumas das considerações:

1. Migração de Objetos de Banco de Dados
   1. Todas as Stored Procedures precisam ser reescritas usando ObjectScript. Este também pode ser um bom momento para mudar para o modelo de objetos, já que você obterá uma tabela de qualquer maneira ao criar uma classe. No entanto, trabalhar com classes permitirá que você escreva métodos (que podem ser chamados como stored procedures) e use todo o poder do paradigma orientado a objetos.
   2. Triggers, Índices e Views são todos suportados pelo IRIS. Você pode até deixar suas Views como estão se as colunas da tabela permanecerem as mesmas, caso não usem nenhuma das funções/sintaxes não suportadas (veja o ponto anterior).
2. A Migração de Definições também é significativa e pode apresentar alguns desafios. Primeiro, você deve corresponder cuidadosamente os tipos de dados do seu DB anterior ao IRIS, especialmente se estiver usando novos tipos complexos. Além disso, tendo mais flexibilidade com os índices, você pode querer redefini-los de forma diferente.

Aqui estão algumas coisas que você precisa considerar ao decidir migrar para o InterSystems IRIS a partir de um banco de dados relacional diferente. É uma decisão estratégica que pode desbloquear benefícios significativos, incluindo escalabilidade, desempenho e eficiência aprimorados. No entanto, um planejamento cuidadoso é crucial para garantir uma transição perfeita e para abordar as necessidades de compatibilidade, transformação de dados e refatoração de aplicativos.