Uma consulta convertida pode ser sintaticamente válida e ainda assim estar errada.
Essa é uma das lições mais importantes em uma migração de banco de dados. Diferentes mecanismos de banco de dados podem aceitar SQL semelhante e ainda produzir resultados diferentes por causa do tratamento de NULL, regras de data, tipos de dados, arredondamento, ordenação ou conversões implícitas.
Use o checklist a seguir antes de considerar o SQL convertido pronto para produção.
1. Confirme o objetivo da consulta
Anote o que a consulta de origem deve realizar.
Ela calcula a receita? Encontra faturas vencidas? Prepara um dashboard? Atualiza o status da conta? O resultado comercial esperado fornece aos revisores algo concreto a preservar durante a conversão.
2. Salve um resultado representativo da origem
Execute a consulta original em dados que incluam casos normais e incomuns.
Inclua:
• Valores NULL
• Strings vazias
• Números zero e negativos
• Datas-limite
• Registros duplicados
• Valores numéricos grandes
• Texto não ASCII, quando relevante
Salve o resultado para que ele possa ser comparado com o banco de dados de destino.
3. Compare as contagens de linhas
Comece pelo sinal mais simples. Se a consulta de origem retornar 2.410 linhas e o destino retornar 2.397, algo mudou.
Contagens de linhas diferentes geralmente apontam para comportamento de junções, filtragem, comparações com NULL, limites de data ou tratamento de duplicatas.
4. Verifique os valores calculados
Compare totais, médias, porcentagens e resultados agrupados.
Preste atenção especial à divisão inteira, precisão decimal, arredondamento, overflow e conversão implícita de tipos. Essas diferenças podem produzir pequenos erros que se tornam significativos em grandes conjuntos de dados.
5. Revise o comportamento de NULL e strings vazias
Os bancos de dados nem sempre tratam valores NULL e strings vazias da mesma forma.
Verifique expressões, concatenação, comparações, funções de agregação e lógica condicional. Uma consulta pode ser executada corretamente enquanto exclui ou altera valores silenciosamente.
6. Teste a lógica de data e hora
A aritmética de datas é um dos pontos mais comuns de problemas em migrações.
Verifique:
• Intervalos adicionados ou subtraídos
• Tratamento de fusos horários
• Limites de meses e anos
• Numeração de semanas
• Truncamento de datas
• Comportamento da data atual e do timestamp atual
Use datas de teste fixas sempre que possível para que a comparação permaneça reproduzível.
7. Confirme a ordenação e a comparação de texto
A ordenação e a diferenciação entre maiúsculas e minúsculas podem afetar ORDER BY, verificações de igualdade, agrupamento e detecção de duplicatas.
Teste textos com diferentes capitalizações, acentos e espaços em branco quando esses valores existirem no conjunto de dados real.
8. Inspecione recursos específicos do banco de dados
Examine atentamente funções específicas do fornecedor, tabelas temporárias, SQL procedural, SQL dinâmico, operações JSON e tipos de dados incomuns.
Essas áreas podem não ter uma tradução segura de um para um e frequentemente exigem que um desenvolvedor ou especialista em banco de dados tome a decisão final.
9. Revise os diagnósticos em vez de ignorá-los
Um aviso não significa necessariamente que a conversão falhou. Ele é um sinal de que o SQL traduzido merece atenção.
Use os diagnósticos como uma fila de revisão. Resolva as diferenças comportamentais de maior risco antes de dedicar tempo a alterações cosméticas.
10. Teste antes da implantação
Execute o SQL convertido em um ambiente seguro com dados representativos. Compare as saídas e teste os relatórios, aplicativos e tarefas agendadas dependentes.
O fluxo de trabalho final deve ser:
Converter
Revisar
Comparar
Testar
Implantar
A qualidade da conversão não é medida apenas pela sintaxe válida. Ela é medida pela confiabilidade com que o SQL de destino preserva o significado da origem.
