Mover SQL de um banco de dados para outro não deveria exigir começar com um editor em branco.
A parte difícil é que PostgreSQL, SQL Server, MySQL, MariaDB, Oracle, Snowflake, Databricks e SQLite compartilham uma linguagem comum, mas implementam muitos detalhes de forma diferente.
As funções mudam. Os tipos de dados diferem. A aritmética de datas segue regras diferentes. Os identificadores usam estilos de aspas diferentes. O SQL procedural pode precisar ser reestruturado.
O Sqlinfy foi criado para esse problema específico.
Um caminho de conversão explícito
Cada conversão começa com duas escolhas claras:
Dialeto de origem
Dialeto de destino
Isso é importante porque a migração de SQL não é uma reescrita genérica de texto. Uma conversão de SQL Server para PostgreSQL segue um caminho diferente de uma conversão de MySQL para Snowflake.
Tornar o caminho explícito reduz a ambiguidade e oferece aos desenvolvedores um ponto de partida repetível.
Resultados legíveis para revisão humana
O SQL convertido deve ser fácil de inspecionar.
Os desenvolvedores precisam entender o que mudou, comparar o resultado com a origem e discutir áreas incertas durante a revisão de código. Resultados legíveis tornam esse trabalho mais rápido do que reconstruir a consulta manualmente.
Os diagnósticos mantêm a incerteza visível
Nem todo recurso de banco de dados tem um equivalente perfeito.
Uma função específica do fornecedor, um tipo de dados incomum, uma conversão implícita ou uma instrução procedural pode exigir atenção especial. Os diagnósticos ajudam a identificar essas áreas para que o desenvolvedor possa analisá-las antes dos testes ou da implantação.
Um diagnóstico não é uma falha. É um sinal útil de que a conversão precisa de avaliação humana.
Fluxos individuais e em lote
As tarefas pequenas geralmente começam com uma consulta colada no conversor.
Migrações maiores podem envolver pastas com arquivos SQL, caminhos de conversão repetidos e muitos scripts aguardando revisão. O processamento em lote ajuda a colocar esse trabalho em uma fila, mantendo os resultados convertidos disponíveis para inspeção.
O mesmo mecanismo em todos os planos
O Sqlinfy não reserva um mecanismo de conversão diferente para planos de preço mais alto.
Os planos pagos aumentam a capacidade prática:
• Scripts maiores
• Mais conversões diárias
• Processamento em lote
• Suporte prioritário
O plano gratuito é uma forma real de testar o fluxo de conversão com seu próprio SQL.
A conversão é a primeira etapa, não a aprovação final
Nenhum conversor automatizado deve substituir os testes.
Após a conversão, compare os resultados da origem e do destino usando dados representativos. Verifique contagens de linhas, totais calculados, valores NULL, datas, ordenação, precisão e qualquer comportamento específico do banco de dados.
O fluxo de trabalho recomendado é:
Entender
Converter
Revisar
Testar
Implantar
O Sqlinfy é intencionalmente focado. Seu trabalho é reduzir a reescrita repetitiva de SQL e oferecer aos desenvolvedores um resultado estruturado e revisável para a próxima etapa da migração.