Hay siete tipos de consulta que se repiten en casi cualquier trabajo de analista de datos, y si las dominas de verdad — no "las reconozco cuando las veo", sino "las escribo sin buscar en Google" — ya resuelves el 80% de lo que te van a pedir en el día a día. No son trucos avanzados: son JOINs, agrupaciones y un puñado de funciones que SQL Server trae desde siempre, pero que casi nadie practica lo suficiente antes de entrar a trabajar.
Esta lista sigue el orden en el que las vemos en nuestro curso de SQL Esencial, que las trabaja sobre la base de datos AdventureWorks — la misma que usan Microsoft y buena parte de los libros de SQL Server, así que lo que practiques ahí se traslada directo a un trabajo real.
1. INNER JOIN: la consulta que más vas a escribir en tu vida
Casi ningún dato útil vive en una sola tabla. Necesitas el nombre del cliente que está en una tabla y el monto de su pedido que está en otra. INNER JOIN te trae solo las filas que coinciden en ambas tablas — si un cliente no tiene pedidos, simplemente no aparece. Es la consulta que separa a quien "sabe SQL" de quien solo sabe hacer SELECT * FROM una tabla.
2. LEFT JOIN: cuando "no aparece" también es un dato
Esta es la que de verdad distingue a alguien con experiencia: LEFT JOIN trae todas las filas de la tabla principal, tengan o no coincidencia en la otra. ¿Por qué importa? Porque "clientes sin ningún pedido en los últimos 6 meses" es exactamente el tipo de pregunta de negocio que un INNER JOIN no puede responder — necesitas ver las filas sin match, no esconderlas.
3. GROUP BY + funciones de agregado: de filas a métricas
- ▸SUM() — ventas totales por mes, por vendedor, por región
- ▸COUNT() — cuántos pedidos, cuántos clientes únicos
- ▸AVG() — ticket promedio, tiempo promedio de entrega
La trampa clásica del examen y de la entrevista: todo campo que pongas en el SELECT y no esté dentro de una función de agregado, tiene que estar en el GROUP BY. Es el error número uno de quien recién está aprendiendo — y el motivo por el que SQL Server te devuelve un error en vez de un resultado raro.
4. Subconsultas: una pregunta dentro de otra pregunta
"Dame los productos que cuestan más que el precio promedio" no se puede responder en una sola pasada: primero necesitas calcular el promedio, y después comparar cada producto contra ese número. Una subconsulta resuelve justo eso — una consulta completa viviendo dentro de la cláusula WHERE de otra. Es el paso natural antes de llegar a los JOINs más complejos.
5. Funciones de fecha: el 90% de los reportes de negocio las necesita
DATEDIFF para calcular cuántos días pasaron entre dos fechas, DATEPART para extraer solo el mes o el año, GETDATE para la fecha actual. Casi todo reporte gerencial se arma alrededor de "ventas de este mes vs el mes pasado" o "clientes que no compran hace más de 90 días", y ambas preguntas se resuelven con funciones de fecha, no con JOINs.
6. Vistas: la consulta que escribes una vez y reusas para siempre
Si escribes el mismo JOIN de cinco tablas cada semana para el mismo reporte, probablemente deberías guardarlo como vista: una consulta guardada que se comporta como si fuera una tabla. El equipo completo consulta "vw_VentasPorRegion" en vez de reescribir el JOIN cada vez, y si cambia la lógica de negocio, la actualizas en un solo lugar.
7. Stored procedures: cuando el reporte deja de ser un SELECT suelto
Acá es donde SQL deja de ser "consultar" y empieza a ser "automatizar". Un stored procedure guarda un bloque completo de lógica — con parámetros, condicionales y hasta bucles — para ejecutarlo con un solo comando. Es lo que te piden cuando el reporte ya no es "tráeme estos datos" sino "actualiza el estado de un pedido, registra el cambio en el historial y notifica si algo falló", todo en una sola transacción segura con COMMIT y ROLLBACK.
Dónde practicar esto sin empezar de cero
El curso completo son 35 clases con certificado y proyectos reales: instalas SQL Server y SSMS, creas tus propias bases y tablas, avanzas por estas siete consultas en orden y cierras con buenas prácticas de seguridad y con IA aplicada a SQL — cómo usarla para escribir y depurar consultas más rápido sin dejar de entender qué está pasando por debajo. Si ya dominas SQL y lo que te falta es Python para automatizar el análisis después de consultar los datos, Python para todos es el complemento natural.
Y si tu siguiente paso es análisis sobre volúmenes grandes de datos en la nube, estas mismas siete consultas se aplican casi sin cambios en BigQuery — cambia la sintaxis en detalles menores, pero la lógica de JOINs y agregaciones es la misma que ya aprendiste acá.