AI y el Procedimiento que Nadie se Atreve a Tocar: Refactorización en SQL Server

En cualquier departamento de Business Intelligence que supere los cinco años de antigüedad, existe un «monstruo». Suele ser un procedimiento almacenado (Stored Procedure) de novecientas o mil líneas, sin un solo comentario, escrito por un consultor que ya no está en la empresa y que gestiona el cálculo crítico de los márgenes o la asignación de costes. Nadie se atreve a tocarlo. Si falla, el informe de ventas del lunes no carga, y si intentas optimizarlo, el riesgo de romper la lógica de negocio es inasumible.

La aparición de modelos de lenguaje de gran tamaño (LLM) y herramientas de IA integradas ha cambiado las reglas del juego. No porque la IA vaya a reescribir el código por nosotros de forma mágica, sino porque ahora tenemos un intérprete capaz de leer lo que nosotros tardaríamos días en procesar. Sin embargo, delegar la comprensión de un proceso crítico a una IA no está exento de riesgos técnicos y de arquitectura que debemos evaluar con criterio de consultor senior.

En este artículo analizamos qué implica realmente que una IA «lea el procedimiento que nadie se atreve a tocar» y cómo podemos aprovechar esta capacidad para sanear nuestra deuda técnica en SQL Server y preparar el camino hacia arquitecturas modernas como Microsoft Fabric.

El problema de la caja negra en SQL Server

El principal problema de los procedimientos antiguos no es solo su longitud, sino el uso de patrones que hoy consideramos anti-patrones en arquitecturas de alto rendimiento. Hablamos de cursores anidados, uso excesivo de tablas temporales sin índices, o lógica condicional basada en variables globales que mutan a lo largo de cientos de líneas. Cuando un modelo de Power BI consume estos datos, cualquier ineficiencia en el origen se traduce en tiempos de refresco inaceptables.

Antes de aplicar cualquier cambio, es fundamental entender el impacto. Muchas veces, el rendimiento se degrada por decisiones de ejecución que SQL Server toma basándose en planes obsoletos. En estos casos, antes de tocar el código, conviene revisar estrategias como el Ajuste automático en SQL Server: FORCE_LAST_GOOD_PLAN en la práctica para estabilizar el entorno antes de la refactorización.

¿Por qué tememos a estos procedimientos?

• Opacidad de la lógica: Las reglas de negocio (por ejemplo, cómo se calcula una devolución en retail) están enterradas en subconsultas con alias poco descriptivos como T1 o tmp_data.
• Efectos secundarios: Procedimientos que actualizan cinco tablas diferentes antes de devolver un conjunto de resultados.
• Dependencias ocultas: Uso de Linked Servers o bases de datos externas que pueden no estar disponibles en entornos de desarrollo.
• Falta de pruebas unitarias: No hay una forma rápida de validar que el resultado tras un cambio sigue siendo correcto para todos los casos de borde.

Cómo usar la IA como intérprete de código legacy

La IA no debe usarse para «corregir» el procedimiento de entrada. El primer paso es la documentación inversa. Al alimentar un LLM con un procedimiento de 900 líneas, el objetivo es obtener un pseudocódigo claro y un mapa de dependencias. Un consultor senior debe supervisar este proceso, validando que la IA no invente (alucine) pasos lógicos que no existen.

-- Ejemplo de patrón problemático que la IA debe identificar
CREATE PROCEDURE dbo.CalcularMargenHistorico
AS
BEGIN
 DECLARE @CursorVentas CURSOR;
 -- La IA debería detectar que este cursor es ineficiente para 1M de filas
 SET @CursorVentas = CURSOR FOR 
 SELECT VentaID, Importe, Coste FROM FactVentas;
 
 OPEN @CursorVentas;
 -- ... cientos de líneas de lógica procedimental ...
END;

Para que la IA sea efectiva, no basta con copiar y pegar el código. Necesita contexto. Debemos indicarle el esquema de las tablas implicadas (solo los nombres de columnas y tipos de datos, nunca los datos reales por privacidad) y cuál es el objetivo final del procedimiento. Solo entonces podrá identificar, por ejemplo, que un OR en una cláusula WHERE está destruyendo el rendimiento y sugerir un cambio hacia UNION ALL, tal como explicamos en nuestro análisis sobre OR en el WHERE y el uso de UNION ALL.

Riesgos: Seguridad y Alucinaciones Técnicas

El mayor error que puede cometer un equipo técnico es confiar ciegamente en la interpretación de la IA. En el ámbito de SQL Server, una pequeña confusión entre un LEFT JOIN y un INNER JOIN en un procedimiento de consolidación financiera puede suponer la pérdida de millones de registros en los informes finales.

Además, es vital entender que la IA lee el código estático, pero no ve el comportamiento dinámico. No sabe cuántas filas hay en cada tabla ni cuál es la distribución de los datos. Para eso, seguimos necesitando leer planes de ejecución en SQL Server y entender los operadores clave que están consumiendo CPU o memoria.

De SQL Legacy a Microsoft Fabric: El camino de la modernización

Si el objetivo de entender ese procedimiento antiguo es migrar a una arquitectura moderna, la IA es una aliada estratégica. Muchos de estos procedimientos almacenados en SQL Server son candidatos perfectos para ser transformados en Notebooks de Spark o flujos de Data Factory en Microsoft Fabric. Sin embargo, no se trata de una traducción literal.

En Fabric, buscamos la simplicidad y la escalabilidad del Lakehouse. Un procedimiento almacenado que hace malabarismos con tablas temporales puede simplificarse a menudo mediante el uso de Medallion Architecture (Bronze, Silver, Gold). Al documentar el procedimiento con IA, podemos identificar qué partes de la lógica pertenecen a la transformación (Silver) y cuáles al modelado final para Power BI (Gold).

Este proceso es crítico para garantizar la frescura de datos en Microsoft Fabric, evitando latencias innecesarias causadas por lógica de negocio mal heredada del on-premises.

Patrones de refactorización recomendados

1. Descomposición: Dividir el procedimiento de 900 líneas en 5 o 6 funciones o procedimientos más pequeños y testeables.
2. Eliminación de cursores: Sustituir la lógica fila a fila por operaciones de conjunto (set-based logic).
3. Tipado fuerte: Asegurar que todas las tablas temporales y variables tengan tipos de datos explícitos y correctos para evitar conversiones implícitas que penalizan el rendimiento.
4. Gestión de errores: Implementar bloques TRY...CATCH robustos y un sistema de logging, similar a la gestión proactiva de errores en Power Query que solemos aplicar en la capa de BI.

Errores comunes al enfrentarse a código antiguo con IA

• Intentar refactorizar todo a la vez: Es mejor usar la IA para entender el código y luego cambiar un solo módulo cada vez, probando los resultados.
• Ignorar el hardware: A veces el problema no es el código, sino que el servidor no tiene memoria suficiente para los Sort o Hash Joins que genera ese procedimiento.
• No usar herramientas de comparación: Después de que la IA sugiera una versión «limpia», no compararla mediante un EXCEPT o un INTERSECT con los resultados de la versión antigua para asegurar paridad de datos.
• Olvidar la documentación: Usar la IA para entender el código pero no pedirle que genere los comentarios y la documentación técnica para el siguiente consultor que llegue.

-- Ejemplo de validación de paridad tras refactorización
SELECT * FROM dbo.ResultadoNuevo
EXCEPT
SELECT * FROM dbo.ResultadoAntiguo;
-- Si esta consulta devuelve filas, la refactorización ha cambiado la lógica de negocio.

Checklist de actuación ante un procedimiento «intocable»

• Auditoría inicial: Ejecuta el procedimiento con STATISTICS IO, TIME ON y guarda el plan de ejecución actual como línea base.
• Anonimización: Prepara el código eliminando cualquier referencia a datos sensibles o infraestructuras privadas antes de usar herramientas de IA.
• Interpretación por bloques: Pide a la IA que explique el código en bloques de no más de 100 líneas para evitar que pierda el contexto o se salte detalles.
• Pruebas de paridad: Crea un entorno de staging donde puedas comparar fila a fila el resultado del código antiguo frente al refactorizado.
• Documentación viva: Una vez entendido el proceso, integra la explicación en tu catálogo de datos o sistema de linaje para que deje de ser una «caja negra».

Preguntas frecuentes

¿Puede la IA optimizar automáticamente el rendimiento de un SP?

No de forma autónoma. Puede sugerir mejores prácticas (como cambiar un cursor por un CTE), pero no conoce las estadísticas de tus tablas ni los índices existentes. La optimización real requiere analizar el plan de ejecución en el entorno de producción.

¿Es seguro pegar mi código SQL en ChatGPT o Copilot?

Depende de la política de tu empresa y de la versión de la herramienta. En entornos corporativos, usa siempre instancias privadas de Azure OpenAI o Copilot con protección de datos comerciales para asegurar que tu código no se use para entrenar modelos públicos.

¿Qué hago si la IA no entiende una parte del procedimiento?

Suele ocurrir con código muy antiguo o funciones propietarias de versiones muy específicas de SQL Server. En ese caso, debes aislar ese fragmento, investigar la documentación oficial de Microsoft y explicarle tú a la IA qué hace esa función para que pueda integrarla en el análisis global.

¿Vale la pena refactorizar si el procedimiento ‘funciona’?

Solo si el coste de mantenimiento, el riesgo de fallo o el impacto en el rendimiento de los informes es alto. Si es un proceso que se ejecuta una vez al mes y tarda 5 minutos, la refactorización puede no tener un ROI claro frente al riesgo de introducir errores.