A conversão de SQL às vezes é descrita como a substituição de uma função de banco de dados por outra. O trabalho real de migração é mais complicado.
Duas funções podem ter nomes semelhantes e ainda assim se comportarem de maneiras diferentes. Dois bancos de dados podem aceitar uma sintaxe semelhante, mas tratar valores NULL, datas, números ou texto de maneiras diferentes.
Um processo de conversão útil precisa considerar esses comportamentos, não apenas a aparência da consulta.
A paginação é um exemplo simples
PostgreSQL e MySQL geralmente limitam os resultados com:
SELECT *
FROM customers
LIMIT 10;
O SQL Server pode expressar a mesma solicitação básica com:
SELECT TOP 10 *
FROM customers;
A alteração da palavra-chave é fácil. A consulta ao redor se torna mais importante quando a paginação também inclui ordenação, deslocamentos ou empates.
A aritmética de datas exige contexto
O MySQL pode adicionar sete dias com:
SELECT DATE_ADD(order_date, INTERVAL 7 DAY)
FROM orders;
O PostgreSQL pode usar:
SELECT order_date + INTERVAL '7 days'
FROM orders;
A sintaxe é diferente, mas uma migração também precisa considerar tipos de dados, fusos horários, limites de meses e a diferença entre uma data e um carimbo de data e hora.
Os valores NULL podem alterar os resultados
O comportamento de NULL afeta comparações, concatenação de strings, expressões condicionais e funções de agregação.
Uma expressão traduzida pode ser válida no banco de dados de destino, mas retornar um resultado diferente quando uma entrada é NULL. Por isso, avisos e dados de teste representativos são importantes.
Os tipos de dados não são rótulos intercambiáveis
Um banco de dados de origem pode usar tipos que não têm um equivalente exato no destino.
A conversão deve considerar:
• Comprimento máximo
• Precisão e escala numéricas
• Suporte a fusos horários
• Comportamento Unicode
• Representação booleana
• Armazenamento de JSON
• Dados binários
Escolher um tipo com nome semelhante não é suficiente se isso alterar os valores que podem ser armazenados.
Os identificadores e as aspas também diferem
O SQL Server geralmente usa colchetes ao redor dos identificadores. O MySQL costuma usar crases. O PostgreSQL e outros sistemas usam aspas duplas em situações específicas.
As regras de uso de aspas interagem com capitalização, palavras reservadas e nomes de esquemas. Um identificador convertido deve ser verificado no contexto do banco de dados de destino.
O SQL procedural exige atenção especial
Procedures armazenadas, variáveis, tratamento de exceções, objetos temporários e SQL dinâmico frequentemente contêm os comportamentos mais específicos do banco de dados.
Essas construções podem exigir uma reestruturação, em vez de uma substituição direta. Um conversor pode fornecer uma primeira versão e diagnósticos, mas um desenvolvedor deve revisar o design final.
O que uma conversão consciente dos dialetos deve fazer
Um conversor de SQL estruturado deve:
• Tornar explícitos os dialetos de origem e destino
• Aplicar regras de tradução consistentes
• Preservar uma estrutura legível
• Destacar mapeamentos incertos ou sensíveis ao comportamento
• Evitar ocultar a necessidade de revisão humana
O objetivo não é prometer uma migração perfeita com um único clique.
O objetivo é reduzir a reescrita repetitiva, tornar visíveis as diferenças importantes e oferecer aos desenvolvedores um ponto de partida mais sólido para os testes.
Os dialetos de SQL compartilham uma base, mas seu comportamento não é idêntico. Uma boa conversão respeita os dois lados dessa realidade.
