SQL básico — consultas

📐 Fundamento

Sintaxis general:

SELECT columnas
FROM tabla
WHERE condicion
ORDER BY columna [ASC|DESC]
LIMIT n;

Todas las columnas

SELECT * FROM producto;

* = "todas las columnas". OK para exploración. Mal en producción — devuelve más datos que los necesarios y se rompe si cambia el esquema.

Columnas específicas

SELECT codigo, nombre, precio FROM producto;

Renombrar (alias)

SELECT nombre AS producto, precio * 1.13 AS precio_con_iva
FROM producto;

Condiciones — WHERE

SELECT * FROM producto WHERE precio > 0.50;
SELECT * FROM producto WHERE stock = 0;
SELECT * FROM producto WHERE nombre LIKE 'Pupusa%';     -- empieza con "Pupusa"
SELECT * FROM producto WHERE codigo IN ('Q', 'R', 'F');
SELECT * FROM producto WHERE precio BETWEEN 0.40 AND 0.60;
SELECT * FROM cliente WHERE email IS NULL;

Operadores:

Ordenar

SELECT * FROM producto ORDER BY precio DESC, nombre ASC;

DESC descendente, ASC ascendente (default).

Limitar

SELECT * FROM producto ORDER BY precio DESC LIMIT 5;     -- los 5 más caros
SELECT * FROM producto ORDER BY id LIMIT 10 OFFSET 20;   -- página 3 si páginas son de 10

OFFSET salta filas. Combinado con LIMIT da paginación.

DISTINCT

Eliminar duplicados:

SELECT DISTINCT cliente_id FROM pedido;

📐 Fundamento

El JOIN combina filas de tablas distintas que cumplen una condición. Es el corazón del modelo relacional.

INNER JOIN

SELECT p.id, c.nombre AS cliente, p.fecha, p.total
FROM pedido AS p
INNER JOIN cliente AS c ON p.cliente_id = c.id;

Devuelve filas donde AMBAS tablas tienen match. Pedidos sin cliente o clientes sin pedidos quedan fuera.

Regla de oro: siempre usá alias (p, c). Hace el SQL legible y permite columnas con mismo nombre.

LEFT JOIN (LEFT OUTER JOIN)

SELECT c.nombre, p.id AS pedido_id, p.fecha
FROM cliente AS c
LEFT JOIN pedido AS p ON c.id = p.cliente_id;

Devuelve todas las filas de la izquierda (cliente). Si no hay match en la derecha, las columnas derechas son NULL. Ejemplo: clientes que aún no pidieron nada.

RIGHT JOIN

Espejo del anterior. Casi nadie lo usa — siempre podés convertir un RIGHT JOIN a LEFT cambiando el orden de las tablas.

FULL OUTER JOIN

Todas las filas de ambos lados, NULL donde no hay match.

CROSS JOIN

Todas las combinaciones (producto cartesiano):

SELECT * FROM cliente CROSS JOIN producto;
-- N clientes × M productos filas

Útil rara vez. Cuidado: explota rápido.

Diagrama mental

JOIN de varias tablas

SELECT c.nombre AS cliente, pr.nombre AS producto, pl.cantidad
FROM pedido AS p
INNER JOIN cliente AS c ON p.cliente_id = c.id
INNER JOIN pedido_linea AS pl ON pl.pedido_id = p.id
INNER JOIN producto AS pr ON pl.producto = pr.codigo
WHERE p.fecha >= '2026-01-01';

Tres JOINs encadenados. Una consulta así te dice quién compró qué en un período.

📐 Fundamento

Las funciones de agregación resumen muchos valores en uno:

SELECT COUNT(*) AS total_clientes FROM cliente;
SELECT AVG(precio), MIN(precio), MAX(precio) FROM producto;
SELECT SUM(total) AS ingreso_total FROM pedido WHERE fecha >= '2026-01-01';

GROUP BY

Para agrupar y agregar por categoría:

SELECT cliente_id, COUNT(*) AS pedidos, SUM(total) AS gastado
FROM pedido
GROUP BY cliente_id;

Devuelve una fila por cliente, con el conteo y la suma.

Regla: las columnas en SELECT deben estar en GROUP BY o ser agregaciones. Sino, error.

-- Mal:
SELECT cliente_id, fecha, COUNT(*) FROM pedido GROUP BY cliente_id;
-- ERROR: fecha no está en GROUP BY ni es agregación

-- Bien:
SELECT cliente_id, COUNT(*), MAX(fecha) AS ultima FROM pedido GROUP BY cliente_id;

HAVING

WHERE filtra antes de agrupar, HAVING filtra después:

SELECT cliente_id, COUNT(*) AS pedidos
FROM pedido
GROUP BY cliente_id
HAVING COUNT(*) > 5;       -- solo clientes con más de 5 pedidos

HAVING es para condiciones sobre agregaciones.

Orden de ejecución (lógico)

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

Aunque el SQL se escribe en otro orden, se evalúa así. Por eso podés usar alias del SELECT en ORDER BY pero no en WHERE.

📐 Fundamento

Una subconsulta es un SELECT dentro de otro:

-- Productos con precio mayor que el promedio
SELECT * FROM producto
WHERE precio > (SELECT AVG(precio) FROM producto);

-- Clientes que pidieron pupusas de queso
SELECT * FROM cliente
WHERE id IN (
    SELECT cliente_id FROM pedido WHERE id IN (
        SELECT pedido_id FROM pedido_linea WHERE producto = 'Q'
    )
);

Tipos:

• Escalar: devuelve un solo valor.
• De fila: devuelve una fila.
• De tabla: devuelve varias filas.
• Correlacionada: referencia columnas de la consulta exterior — se evalúa por cada fila del exterior.

-- Subquery correlacionada: clientes con su pedido más reciente
SELECT c.nombre, (
    SELECT MAX(fecha)
    FROM pedido p
    WHERE p.cliente_id = c.id
) AS ultima_compra
FROM cliente c;

CTE — Common Table Expression (WITH)

WITH ventas_por_cliente AS (
    SELECT cliente_id, COUNT(*) AS n_pedidos, SUM(total) AS gastado
    FROM pedido
    GROUP BY cliente_id
)
SELECT c.nombre, vc.n_pedidos, vc.gastado
FROM cliente c
JOIN ventas_por_cliente vc ON c.id = vc.cliente_id
WHERE vc.gastado > 100;

WITH te deja nombrar una subconsulta. Hace queries complejas mucho más legibles. Casi todo SQL moderno lo soporta.

📐 Fundamento

Buscar WHERE codigo = 'Q' en una tabla con 10 millones de filas. Sin índice, el DBMS escanea todas — segundos. Con índice sobre codigo, lo encuentra en microsegundos.

Crear:

CREATE INDEX idx_pedido_cliente ON pedido(cliente_id);
CREATE INDEX idx_pedido_fecha ON pedido(fecha);
CREATE UNIQUE INDEX idx_cliente_email ON cliente(email);

Cuándo crear índices:

• Columnas usadas frecuentemente en WHERE, JOIN, ORDER BY.
• PK e UNIQUE ya están indexadas automáticamente.

Cuándo NO:

• Tabla chica (decenas de filas). El índice no compensa.
• Columna con pocos valores distintos (booleano). Índice no ayuda.
• Tabla con muchísimas escrituras y pocas lecturas — los índices se mantienen al insertar/actualizar.

Cómo el DBMS los usa. El optimizador lee tu query, mira las estadísticas y decide qué índices usar. Para inspeccionar:

EXPLAIN ANALYZE SELECT * FROM pedido WHERE cliente_id = 5;

Te muestra el plan de ejecución: cómo el DBMS va a resolver la consulta. Es la herramienta clave para optimizar.

Tipos de índice:

• B-tree (default): bueno para igualdad y rangos.
• Hash: igualdad pura, rápido.
• GiST, GIN: para búsqueda full-text, geográfica.

Profundizamos más en la materia siguiente.