Una consulta convertida puede ser sintácticamente válida y aun así ser incorrecta.
Esta es una de las lecciones más importantes de la migración de bases de datos. Distintos motores de bases de datos pueden aceptar un SQL similar y producir resultados diferentes debido al tratamiento de NULL, las reglas de fechas, los tipos de datos, el redondeo, la ordenación o las conversiones implícitas.
Usa la siguiente lista de comprobación antes de considerar que el SQL convertido está listo para producción.
1. Confirma el propósito de la consulta
Anota lo que se espera que logre la consulta de origen.
¿Calcula ingresos? ¿Busca facturas vencidas? ¿Prepara un panel? ¿Actualiza el estado de una cuenta? El resultado empresarial esperado proporciona a los revisores algo concreto que deben proteger durante la conversión.
2. Guarda un resultado representativo del origen
Ejecuta la consulta original con datos que incluyan casos normales y excepcionales.
Incluye:
• Valores NULL
• Cadenas vacías
• Números cero y negativos
• Fechas límite
• Registros duplicados
• Valores numéricos grandes
• Texto no ASCII cuando sea pertinente
Guarda el resultado para poder compararlo con la base de datos de destino.
3. Compara los recuentos de filas
Empieza por la señal más sencilla. Si la consulta de origen devuelve 2,410 filas y la de destino devuelve 2,397, algo ha cambiado.
Los recuentos de filas diferentes suelen indicar un comportamiento distinto de las uniones, los filtros, las comparaciones con NULL, los límites de fechas o el tratamiento de duplicados.
4. Comprueba los valores calculados
Compara totales, promedios, porcentajes y resultados agrupados.
Presta especial atención a la división entera, la precisión decimal, el redondeo, el desbordamiento y la conversión implícita de tipos. Estas diferencias pueden producir errores pequeños que se vuelven significativos en conjuntos de datos grandes.
5. Revisa el comportamiento de NULL y las cadenas vacías
Las bases de datos no siempre tratan los valores NULL y las cadenas vacías de la misma forma.
Comprueba las expresiones, la concatenación, las comparaciones, las funciones de agregación y la lógica condicional. Una consulta puede ejecutarse correctamente y, aun así, excluir o modificar valores silenciosamente.
6. Prueba la lógica de fechas y horas
La aritmética de fechas es uno de los problemas más comunes durante una migración.
Verifica:
• Intervalos añadidos o restados
• Tratamiento de zonas horarias
• Límites de meses y años
• Numeración de semanas
• Truncamiento de fechas
• Comportamiento de la fecha actual y la marca de tiempo actual
Cuando sea posible, usa fechas de prueba fijas para que la comparación sea repetible.
7. Confirma la ordenación y la comparación de texto
La intercalación y la sensibilidad a mayúsculas y minúsculas pueden afectar a ORDER BY, las comprobaciones de igualdad, la agrupación y la detección de duplicados.
Prueba texto con distintas mayúsculas, acentos y espacios en blanco cuando esos valores existan en el conjunto de datos real.
8. Inspecciona las funciones específicas de la base de datos
Examina detenidamente las funciones específicas del proveedor, las tablas temporales, el SQL procedimental, el SQL dinámico, las operaciones JSON y los tipos de datos inusuales.
Estas áreas pueden no tener una traducción segura uno a uno y a menudo requieren que un desarrollador o especialista en bases de datos tome la decisión final.
9. Revisa los diagnósticos en lugar de ignorarlos
Una advertencia no implica necesariamente que la conversión haya fallado. Es una señal de que el SQL traducido merece atención.
Usa los diagnósticos como una cola de revisión. Resuelve las diferencias de comportamiento de mayor riesgo antes de dedicar tiempo a cambios estéticos.
10. Haz pruebas antes de la implementación
Ejecuta el SQL convertido en un entorno seguro con datos representativos. Compara los resultados y prueba los informes, las aplicaciones y los trabajos programados dependientes.
El flujo de trabajo final debe ser:
Convertir
Revisar
Comparar
Probar
Implementar
La calidad de la conversión no se mide únicamente por la sintaxis válida. Se mide por la fiabilidad con la que el SQL de destino conserva el significado del origen.
