SQL desde cero: 12 consultas para responder preguntas de negocio

SQL es el idioma con el que se le hacen preguntas a los datos. No necesitas ser ingeniero de datos ni haber estudiado matemáticas avanzadas: con doce consultas bien entendidas resuelves la mayor parte de las preguntas que aparecen en un trabajo real (cuánto vendimos, quién compró, qué producto rinde más, qué cliente se fue). Esta guía no es una lista de comandos para memorizar: es un recorrido por las preguntas típicas y la consulta exacta que las responde, con un ejemplo trabajado de punta a punta.

Si vienes del mundo de las planillas, el cambio mental es simple: en Excel mirás celdas, en SQL describís qué querés ver y el motor busca los datos por vos. Esa diferencia es la que permite repetir el mismo cálculo cada mes con un solo comando y sin errores de copiado.

Qué necesitas para practicar hoy

No hace falta instalar nada complicado ni pagar un servidor. Tienes tres caminos razonables:

• PostgreSQL local. Es el motor más usado en serio y lo instalas con un paquete del sistema. Ideal si querés aprender sintaxis que después reutilizas en el trabajo.
• SQLite. Un único archivo y cero configuración. Perfecto para practicar las consultas de esta guía, aunque algunas funciones de fechas cambian.
• Un servicio online de práctica. Sirve para empezar, pero evita depender de la interfaz: lo que necesitas aprender es el lenguaje, no el botón.

Con cualquiera de los tres vas a necesitar una tabla. Crea un esquema mínimo de práctica con tres tablas relacionadas: clientes, pedidos y productos. Con eso alcanza para el 100% de los ejemplos de abajo.

El modelo mental: tablas, filas y relaciones

Antes de escribir consultas conviene entender tres ideas:

1. Una tabla es una grilla con columnas fijas.
2. Una fila es un caso: un cliente, un pedido, un producto.
3. Una clave conecta tablas: pedidos.cliente_id apunta a clientes.id.

Toda consulta tiene la misma anatomía: SELECT (qué columnas), FROM (de qué tabla), WHERE (qué filas), GROUP BY (cómo agrupar), ORDER BY (cómo ordenar) y LIMIT (cuántas traer). El orden en que se escribe no es el orden en que se ejecuta, y entender eso evita la mitad de los errores de principiante: primero se filtra, después se agrupa, y recién al final se ordena y se corta.

Las 12 consultas que resuelven el trabajo diario

1. Traer una lista filtrada y ordenada

SELECT nombre, ciudad, fecha_alta
FROM clientes
WHERE ciudad = 'Rosario'
ORDER BY fecha_alta DESC
LIMIT 20;

Sirve para casi cualquier pedido de tipo "dame una lista de…".

2. Contar y sumar por grupo

SELECT categoria, COUNT(*) AS pedidos, SUM(total) AS facturado
FROM pedidos
GROUP BY categoria
ORDER BY facturado DESC;

Regla de oro: toda columna del SELECT que no esté dentro de una función de agregación debe estar en el GROUP BY.

3. Filtrar grupos con HAVING

SELECT cliente_id, COUNT(*) AS pedidos
FROM pedidos
GROUP BY cliente_id
HAVING COUNT(*) > 5
ORDER BY pedidos DESC;

WHERE filtra filas; HAVING filtra resultados ya agrupados. Confundirlos es el error más común al empezar.

4. Cruzar dos tablas con INNER JOIN

SELECT c.nombre, SUM(p.total) AS facturado
FROM clientes c
JOIN pedidos p ON p.cliente_id = c.id
WHERE p.fecha >= '2026-01-01'
GROUP BY c.nombre
ORDER BY facturado DESC;

El JOIN interno devuelve solo las filas que existen en ambas tablas.

5. Encontrar lo que falta con LEFT JOIN

SELECT c.nombre
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id = c.id
WHERE p.id IS NULL;

Esta es la consulta clásica para responder "¿qué clientes nunca compraron?". El truco de IS NULL sobre la tabla derecha es el patrón que hay que recordar.

6. Clasificar con CASE WHEN

SELECT nombre,
       CASE
         WHEN total >= 100000 THEN 'alto'
         WHEN total >= 30000 THEN 'medio'
         ELSE 'bajo'
       END AS segmento
FROM pedidos;

7. Trabajar con fechas

SELECT DATE_TRUNC('month', fecha) AS mes, SUM(total) AS facturado
FROM pedidos
GROUP BY 1
ORDER BY 1;

En PostgreSQL, DATE_TRUNC agrupa por período. En SQLite se usa strftime. Aprender la versión de un solo motor primero evita confusiones.

8. Comparar contra un valor de referencia

SELECT nombre, total
FROM pedidos
WHERE total > (SELECT AVG(total) FROM pedidos)
ORDER BY total DESC;

Útil para "¿qué pedidos están por encima del promedio?".

9. Encadenar pasos con CTE

WITH por_cliente AS (
  SELECT cliente_id, SUM(total) AS facturado
  FROM pedidos
  GROUP BY cliente_id
)
SELECT * FROM por_cliente WHERE facturado > 50000;

La CTE (WITH) es la herramienta que hace legible una consulta larga: cada bloque resuelve un paso con nombre propio.

10. Rankear con funciones de ventana

SELECT vendedor,
       SUM(total) AS facturado,
       RANK() OVER (ORDER BY SUM(total) DESC) AS puesto
FROM pedidos
GROUP BY vendedor;

Las funciones de ventana calculan sin colapsar las filas. Son la respuesta cuando alguien pide "el top 3 por cada región".

11. Manejar nulos con COALESCE

SELECT nombre, COALESCE(telefono, 'sin dato') AS contacto
FROM clientes;

Los nulos no son cero ni texto vacío: si no los tratás, cualquier promedio o concatenación te va a mentir.

12. Detectar duplicados

SELECT email, COUNT(*) AS veces
FROM clientes
GROUP BY email
HAVING COUNT(*) > 1;

Antes de confiar en un conteo de clientes, revisá si hay duplicados. Es el control de calidad más rápido que existe.

Ejemplo trabajado: de la pregunta al resultado

Supongamos que tu jefe pregunta: "¿Cuáles fueron los 3 productos con más facturación en el último trimestre y qué porcentaje representan del total?". La consulta completa se arma en dos pasos con una CTE:

WITH ventas AS (
  SELECT producto_id, SUM(total) AS facturado
  FROM pedidos
  WHERE fecha >= DATE '2026-07-01'
    AND fecha < DATE '2026-10-01'
  GROUP BY producto_id
)
SELECT pr.nombre,
       v.facturado,
       ROUND(100.0 * v.facturado / (SELECT SUM(facturado) FROM ventas), 1) AS porcentaje
FROM ventas v
JOIN productos pr ON pr.id = v.producto_id
ORDER BY v.facturado DESC
LIMIT 3;

Cómo leer el resultado y qué verificar:

Verificación	Pregunta que responde	Señal de alarma
Suma total	¿Los 3 productos suman un porcentaje creíble?	Más de 100% indica duplicación por join
Rango de fechas	¿El trimestre está completo?	Falta el último día o el primer mes
Nulos	¿Hay productos sin nombre?	Un join mal armado
Repetidos	¿El mismo producto aparece dos veces?	Claves duplicadas en la tabla de productos

Este pequeño ritual de cuatro chequeos evita el 90% de los reportes equivocados que se envían por apuro.

Cómo saber si tu consulta te está mintiendo

• Duplicación por join. Si un pedido tiene tres líneas y cruzás por producto, un SUM sobre pedidos puede contar tres veces. Agregá por la tabla correcta o usá DISTINCT con criterio.
• Nulos en agregaciones. AVG ignora los nulos; COUNT(columna) también. Si quieres contar filas totales, usa COUNT(*).
• Fechas y zonas horarias. Un pedido de las 23:30 puede caer en el día siguiente según la zona. Define siempre en qué zona estás reportando.
• Totales que no cierran. Si el total del reporte no coincide con el total de la facturación, la diferencia suele ser un filtro de estado (cancelado, borrador) que olvidaste.
• Datos sucios. Un mismo cliente escrito de dos formas distintas son dos clientes para el motor. Ninguna consulta arregla eso: hay que normalizar.

Errores frecuentes al empezar

1. Olvidar la columna de agrupación en el GROUP BY.
2. Usar WHERE para filtrar el resultado de una suma en lugar de HAVING.
3. Escribir JOIN sin condición ON y generar un producto cartesiano.
4. Comparar texto con números ('20' contra 20) y creer que el motor "debería entender".
5. Confiar en SELECT * en consultas que después hay que mantener.
6. No revisar el plan de ejecución cuando la consulta tarda.
7. Asumir que el orden de las filas es estable sin ORDER BY.
8. Mezclar comillas simples y dobles según el motor.

Limitaciones: cuándo SQL no alcanza

SQL es extraordinario para describir y agregar datos, y limitado para otras cosas:

• Preguntas causales. "¿Por qué bajaron las ventas?" no se responde con una consulta: necesitas comparar hipótesis, y eso suele requerir experimentos o análisis fuera de la base.
• Datos que no están en la base. Si la información vive en planillas sueltas o correos, primero hay que integrarla.
• Modelos predictivos. SQL calcula; no proyecta escenarios ni mide probabilidades más allá de lo que ya está en las tablas.
• Rendimiento extremo. Millones de filas con joins complejos requieren índices, particiones o un motor analítico. Eso ya es territorio de ingeniería de datos.
• Permisos. Muchas veces la consulta es correcta y el problema es que no tienes acceso a la tabla correcta.

Practicar con IA sin depender de ella

Un asistente de IA puede explicarte una consulta, proponerte datos de prueba o ayudarte a traducir una pregunta de negocio a SQL. Lo que no debería hacer es reemplazar tu criterio: si no sabés leer el resultado, no podés detectar cuándo el asistente inventó una columna o asumió un join incorrecto. Un buen ejercicio es pedirle que te explique una consulta línea por línea, escribir tu propia versión y recién después comparar. En la biblioteca de prompts de Cursalo hay plantillas para ese tipo de práctica guiada.

Preguntas frecuentes

¿Cuánto tiempo lleva aprender lo necesario para trabajar? Con práctica constante de 30 a 45 minutos por día, las doce consultas de esta guía se dominan en tres o cuatro semanas. Lo que lleva más tiempo es entender el modelo de datos de cada empresa.

¿Empiezo por SQL o por Python? Si tu objetivo es analizar datos, SQL primero. Resuelve las preguntas de negocio y Python complementa cuando necesitas repetir procesos o trabajar con archivos.

¿Necesito saber matemática o estadística? Para estas consultas, no. Para interpretar resultados (promedios, distribuciones, correlaciones) conviene estudiar estadística descriptiva básica.

¿MySQL es muy distinto de PostgreSQL? La lógica es la misma; cambian funciones de fecha, tipos y detalles de sintaxis. Aprende un motor bien y la migración es cuestión de días.

¿Puedo practicar solo con datos inventados? Sí, y conviene: crear tus propias tablas de prueba te obliga a pensar el modelo de datos. Después busca un conjunto real y sucio para enfrentar casos raros.

¿Vale la pena aprender SQL si uso herramientas con interfaz visual? Más que nunca: las herramientas visuales generan SQL, y entender ese SQL es lo que te permite auditar un número que no cierra.

Siguiente paso

Si quieres convertir esta base en una habilidad aplicable al trabajo, el siguiente paso es practicar con un caso completo que incluya datos sucios, preguntas ambiguas y un reporte final. En el blog de análisis de datos hay un recorrido de caso completo, y en la categoría Aprender IA vas a encontrar guías complementarias. Si preferís una ruta guiada con práctica y revisión, revisa los cursos de Cursalo y el detalle de precios para elegir el formato que te conviene.