Respuesta

Históricamente, las tareas de informes dinámicos con un número variable de agrupaciones no estaban previstas en el estándar SQL, ya que este está diseñado para consultas estáticamente definidas con un esquema de resultado claramente definido. Con la aparición de plataformas de BI y tableros interactivos, los programadores comenzaron a buscar maneras de construir consultas SQL "al vuelo" para generar múltiples cortes de datos complejos según lo solicitado por el usuario.

Problema — No se puede programar SQL con la lógica normal de if/else dentro de SELECT; el número de columnas, los propios campos e incluso GROUP BY se definen solo en la etapa de compilación de la consulta. Si el usuario desea un corte por varios campos arbitrarios, es necesario construir dinámicamente el texto de la consulta y ejecutarlo a través de EXECUTE/Dynamic SQL.

Solución:

Se implementa la generación de código SQL en una aplicación externa con la posterior llamada a través de EXEC/EXECUTE. En algunos casos, para tareas simples, se utilizan CASE y plantillas rígidas, pero para flexibilidad siempre se recurre a SQL dinámico:

Ejemplo de código (Pseudocódigo):

-- En el lado de la aplicación (por ejemplo, Python)
groups = ['region', 'channel', 'month']
columns = [f'SUM({col}) AS {col}_sum' for col in selected_metrics]
group_by = ', '.join(groups)
selects = ', '.join(groups + columns)

query = f'SELECT {selects} FROM sales GROUP BY {group_by}'
-- Luego se envía esta consulta a través de la interfaz application/sql

En bases de datos que soportan EXECUTE:

DECLARE @sql NVARCHAR(MAX);
SET @sql = N'SELECT ' + @selects + ' FROM sales GROUP BY ' + @group_by + ';';
EXEC sp_executesql @sql;

Características clave:

Requiere la validación de variables para evitar inyecciones SQL
Casi siempre está relacionado con la arquitectura de la aplicación; se implementan plantillas fuera de SQL para SELECT/GROUP BY
Con un gran número de opciones, se requiere un constructor de consultas inteligente o un motor de plantillas

Preguntas trampa.

¿Es posible implementar un cambio dinámico del número de columnas (pivot/unpivot) solo a través de un SELECT estándar sin SQL dinámico?

No; solo se pueden "desplegar" valores conocidos de antemano a través de CASE/DECODE, pero un número desconocido de columnas se logra solo de manera dinámica.

¿Garantiza su lógica de SQL dinámico protección contra inyecciones si utiliza concatenación de cadenas?

No, la concatenación manual de cadenas representa un riesgo constante de inyección SQL. Es esencial validar la lista de campos/agrupaciones mediante un whitelisting, evitar fragmentos proporcionados por el usuario sin verificación, y lo que es mejor, utilizar parámetros donde sea posible.

¿Puede GROUP BY aceptar una lista de columnas a través de una variable?

El SQL estándar no admite la transmisión de una lista de campos a GROUP BY a través de una variable/parámetro. Es necesario formar dinámicamente el texto de la consulta; no se puede simplemente usar una variable en la lista de GROUP BY.

Errores comunes y anti-patrones

Nombres de campos de usuario no verificados — inyecciones
Lista de campos codificada — falta de flexibilidad
No tener en cuenta posibles valores nulos en grupos

Ejemplo de la vida real

Caso negativo

Un ingeniero de BI permitió que el usuario enviara directamente desde la interfaz de la aplicación los nombres de los campos para el informe, sin filtrarlos a través del whitelisting. Como resultado, al probar inyecciones, la tabla de producción fue "comprometida" debido al código malicioso inyectado en el nombre del campo.

Ventajas:

Máxima flexibilidad en la construcción de informes

Desventajas:

La seguridad se ve comprometida debido a variables no preparadas

Caso positivo

Un ingeniero implementó una validación estricta de nombres; el usuario solo podía elegir entre columnas permitidas (de config/metadata), el SQL dinámico solo se generaba de acuerdo con el whitelisting, y no había vías para la inyección.