SQL complejo.
Un resultado claro.

Cómo comprobar una consulta corregida y comparar el rendimiento

Antes de modificar el SQL conviene dejar constancia del resultado que se considera correcto: columnas que lo componen, reglas de selección, nivel de detalle, repeticiones permitidas y forma de calcular las sumas. El ejemplo de control incluye un esquema pequeño, registros anonimizados y la respuesta esperada. Este conjunto ayuda a distinguir un error de sintaxis de una interpretación incorrecta del informe.

La comprobación de la optimización consta de dos partes. Primero se comparan los resultados de la consulta original y de la modificada: número de filas, claves, sumas de control de los indicadores y ejemplos dudosos. Después se comparan las mediciones sobre un volumen de datos acordado. Una respuesta rápida que pierde filas no se considera un resultado útil de la optimización.

• Se indican la versión del sistema de gestión de bases de datos, los parámetros de la consulta y el volumen habitual de las tablas.
• Se guardan el plan de ejecución, las condiciones de medición y la información sobre la carga concurrente.
• Para los cambios en los índices se describen los comandos propuestos y las restricciones asociadas.
• En las explicaciones finales se distinguen la lógica corregida, el efecto obtenido y los cuellos de botella que persisten.

En PostgreSQL, el modo EXPLAIN ANALYZE ejecuta realmente la consulta examinada. Por ello, su uso para operaciones que modifican datos y consultas de gran carga se acuerda previamente; es preferible utilizar una copia preparada para pruebas. Un plan sin datos reales es útil para el análisis inicial, pero no sustituye la comprobación del resultado obtenido en el escenario de uso.

Qué comprobar al migrar lógica SQL entre sistemas de gestión de bases de datos

La migración de un informe o procedimiento se evalúa por su comportamiento con los datos acordados. Además de comprobar que se ejecuta correctamente, se verifican las reglas de tratamiento de valores ausentes, conversiones de tipos, redondeo, fechas y límites temporales. Incluso un pequeño cambio en una condición de unión o un filtro puede alterar las sumas finales en una consulta aparentemente similar.

Conjunto de control para la migración

1. SQL original o código del procedimiento con la descripción de los parámetros y del resultado esperado.
2. Estructura de las tablas utilizadas, tipos de columnas, restricciones y dependencias de otras funciones.
3. Ejemplos de datos habituales y casos límite: ausencia de un registro, repetición, valor vacío, cambio de fecha, importe negativo o cero.
4. Resultado del sistema original para estos ejemplos y explicación de las reglas de negocio relevantes.
5. Condiciones de ejecución: periodicidad, volumen de datos, tiempo permitido y restricciones de acceso.

Si el procedimiento modifica datos, se examinan por separado la secuencia de operaciones, la gestión del error y el estado de las tablas tras una ejecución incompleta. Para las consultas de informes se comprueba que el nivel de detalle sea el mismo: resultado por documento, línea de documento o grupo de objetos. Al reescribir la consulta no se deben sustituir estos niveles sin advertirlo.

Después de la migración conviene guardar el script SQL, la lista de cambios y los resultados de control. Las dependencias no resueltas se indican explícitamente: por ejemplo, no se ha facilitado una función invocada o se desconoce la regla de cumplimentación de un campo. Esta lista permite continuar el trabajo desde una cuestión concreta y acordar las comprobaciones posteriores sin facilitar datos de producción ni accesos innecesarios.