Consultas con SELECT

Una consulta pide datos a una base de datos. Una consulta SELECT sencilla lee la tabla almacenada sin modificarla. SELECT indica las columnas que se mostrarán y FROM indica la tabla que se leerá.

Los ejemplos de texto utilizan la comparación de igualdad habitual de SQLite y PostgreSQL, que distingue mayúsculas y minúsculas. La configuración de intercalación puede cambiar cómo se compara y ordena el texto.

Dos tablas para trabajar

La tabla employees tiene estas ocho filas. salary es el salario anual en u.m.; hire_date es texto con el formato YYYY-MM-DD. NULL marca un valor ausente.

La tabla products registra los precios en u.m. y las existencias en unidades del almacén.

Lee la estructura de la consulta

SELECT city, first_name
FROM employees;

El conjunto de resultados es otra tabla: ocho filas y dos columnas, con city primero. No hay ningún filtro, así que cada empleado aporta una fila. SQL no garantiza ningún orden de filas hasta que añadas ORDER BY.

SELECT * FROM products; muestra todas las columnas en el orden definido en la tabla. El asterisco resulta útil para explorar. En una consulta guardada, indicar los nombres de las columnas mantiene el resultado centrado en lo necesario e impide que una nueva columna de la tabla cambie su estructura.

Haz que la sintaxis sea legible

Separa las columnas con comas, sin una coma final antes de FROM. Termina la sentencia con punto y coma. Las palabras clave no distinguen mayúsculas y minúsculas, por lo que select funciona, pero las mayúsculas facilitan localizar las cláusulas. Los espacios y los saltos de línea separan palabras; no cambian el significado de esta consulta. Un comentario -- continúa hasta el final de su línea.

Los nombres deben corresponder al esquema. Si frist_name provoca un error de columna inexistente, compara su escritura con first_name. SQL estándar utiliza comillas dobles para los nombres que contienen espacios o palabras reservadas, como "order date". PostgreSQL convierte los nombres sin comillas a minúsculas, mientras que "City" solicita ese nombre exacto con mayúscula inicial. MySQL normalmente utiliza acentos graves; las comillas dobles identifican nombres en su modo ANSI_QUOTES. SQL Server también acepta corchetes y acepta comillas dobles cuando QUOTED_IDENTIFIER está activado, su configuración predeterminada.

Un valor repetido en el resultado de una consulta suele ser útil. Varios empleados pueden vivir en la misma ciudad y cada uno sigue necesitando una fila. Utiliza DISTINCT cuando la pregunta pida valores distintos o combinaciones distintas.

Elige qué debe contar como duplicado

SELECT DISTINCT city
FROM employees;

El resultado contiene Chicago, Denver y Boston, sin un orden garantizado. Un simple SELECT city devolvería ocho filas porque cada empleado aporta una ciudad. Añadir DISTINCT reduce lo mostrado a tres valores distintos. Los ocho registros de empleados permanecen almacenados.

La comparación incluye todas las columnas seleccionadas. Considera:

SELECT DISTINCT department, city
FROM employees;

Ana y Chloe aportan (Sales, Chicago), así que ese par aparece una sola vez. Emma aporta (Sales, Denver), que es distinto y se conserva. Los demás pares son (IT, Denver), (Marketing, Boston), (IT, Chicago), (NULL, Boston) y (Marketing, Chicago). Hay siete filas en el resultado. Los departamentos repetidos se mantienen porque un departamento asociado a otra ciudad constituye una fila de resultado distinta.

Escribe DISTINCT una sola vez, justo después de SELECT. Se aplica a toda la fila seleccionada. Colocarlo entre nombres de columna, como en SELECT department, DISTINCT city, es un error de sintaxis.

Presta atención a las columnas que incluyes

Si añades employee_id a las columnas seleccionadas, cada fila pasa a ser distinta. SELECT DISTINCT employee_id, city FROM employees; sigue devolviendo ocho filas: cada identificador es único, incluso cuando se repite la ciudad. Para responder «¿Qué ciudades tienen empleados?», selecciona solo la ciudad. Para responder «¿Qué empleados viven en cada ciudad?», conserva las columnas identificativas y espera que las ciudades se repitan.

En este paso de eliminación de duplicados, los NULL repetidos se tratan como duplicados. SELECT DISTINCT department FROM employees; devuelve Sales, IT, Marketing y una fila NULL. La fila NULL indica que falta un departamento; no es el nombre de un cuarto departamento. Esta regla de duplicados difiere de NULL = NULL, que da desconocido en un filtro.

Las comparaciones de texto siguen una intercalación, las reglas de la base de datos para buscar coincidencias y ordenar texto. Con las comparaciones habituales que distinguen mayúsculas y minúsculas utilizadas en estos ejemplos de SQLite y PostgreSQL, Chicago y chicago son valores distintos. Una lista con DISTINCT puede revelar diferencias en el uso de mayúsculas y minúsculas. Eliminar las repeticiones de lo mostrado no corrige la escritura de los datos almacenados.

Combina DISTINCT con una lista breve ordenada

SELECT DISTINCT city
FROM employees
ORDER BY city
LIMIT 2;

Primero desaparecen las ciudades duplicadas. Después se ordenan las tres ciudades. Por último, quedan dos filas de resultado: Boston y Chicago, en ese orden. Aplicar primero el límite a las filas de empleados respondería a otra pregunta.

En una consulta con DISTINCT, incluye las columnas de ordenación en la lista SELECT. PostgreSQL lo exige; SQLite permite algunas consultas que ordenan por una columna no seleccionada, pero elegir entre distintos valores ocultos hace que su ordenación sea difícil de interpretar. Si un resultado presenta repeticiones inesperadas, revisa qué columnas has seleccionado antes de decidir si la consulta necesita DISTINCT.

La cláusula WHERE conserva una fila solo cuando su condición es verdadera. Se escribe después de FROM y puede comprobar cualquier columna de la tabla, incluida una que no muestres.

Relaciona las palabras con el operador

<> es la forma de SQL estándar para «distinto de». Las cinco bases de datos tratadas aquí también aceptan !=. Utiliza un solo signo igual para la igualdad. SQLite acepta ==, pero PostgreSQL rechaza esa forma.

Sigue una fila situada en el límite

SELECT first_name, salary
FROM employees
WHERE salary > 60000;

Ben tiene 71 000, Emma tiene 65 000 y Farid tiene 83 000. Esas son las tres filas que cumplen la condición, sin un orden indicado. David gana exactamente 60 000. Su fila no cumple > 60000 porque «más de» excluye la igualdad.

Cambia solo el operador a >=. David se incorpora ahora al resultado, que pasa a tener cuatro filas. Así se distingue «al menos 60 000» de «más de 60 000». Una comprobación de límites útil pregunta qué ocurre con un valor exactamente igual al umbral; los valores muy superiores no permiten detectar ese error.

Para «como máximo 20,50», un precio de 20,50 cumple la condición y uno de 20,51 no. Cuando una petición indique un límite inferior y otro superior, comprueba cada extremo por separado antes de unir las pruebas.

Escribe los valores numéricos como números

Utiliza solo cifras en las condiciones SQL: 60000, sin separadores de millares ni símbolos monetarios. Una coma separa elementos de SQL; WHERE salary > 60,000 es un error de sintaxis. Los valores decimales utilizan un punto, como en WHERE price < 20.50. Los salarios y los precios deben estar en columnas numéricas para que las comparaciones utilicen su magnitud numérica.

El texto que parece numérico sigue las reglas del texto cuando se compara como texto. El valor de texto '9' se ordena después de '10' porque su primer carácter viene después. Eso informa sobre caracteres, no sobre si nueve es mayor que diez. Lee el tipo de datos de la columna antes de interpretar una comparación inesperada.

Filtra sin mostrar la columna comprobada

SELECT first_name
FROM employees
WHERE salary < 50000;

Chloe y Grace cumplen la condición. Sus salarios se utilizan para comprobar las filas, pero no aparecen en el resultado. No necesitas añadir el salario a SELECT para que funcione el filtro. Al comprobar una consulta, mostrarlo temporalmente puede ayudarte a revisar por qué cada fila cumplió la condición.

La igualdad sobre una clave primaria permite buscar directamente un registro: WHERE employee_id = 6 encuentra a Farid. Una clave primaria identifica una fila, por lo que esa igualdad no puede devolver varios empleados con el mismo identificador.

Los datos ausentes requieren atención por separado. WHERE stock <> 0 devuelve seis productos. Lamp Shade queda fuera porque sus existencias conocidas son cero. Bookshelf también queda fuera: sus existencias son NULL, por lo que la comparación es desconocida y WHERE no lo conserva. Una prueba de desigualdad no añade los valores ausentes a su resultado.

Las condiciones de texto y fecha necesitan valores con un formato que la base de datos pueda interpretar. Un valor mal escrito puede no devolver filas sin avisar, mientras que una comilla ausente puede convertir ese valor en un nombre de columna.

Distingue un valor de un nombre

SELECT first_name
FROM employees
WHERE city = 'Chicago';

Las comillas simples hacen que 'Chicago' sea un valor de texto. El resultado contiene Ana, Chloe, Farid y Hugo. Sin comillas, Chicago se interpreta como un nombre, así que la base de datos busca una columna con ese nombre. Las comillas dobles estándar también delimitan nombres. PostgreSQL rechaza city = "Chicago" cuando no existe esa columna. Algunas configuraciones de SQLite aceptan cadenas entre comillas dobles como una función heredada; utiliza siempre comillas simples para los valores.

Un apóstrofo dentro de un valor se duplica:

SELECT first_name
FROM employees
WHERE last_name = 'O''Neill';

Así se encuentra a Hugo. Las dos comillas simples contiguas representan un apóstrofo dentro del valor; las comillas exteriores marcan su inicio y su final. SQL estándar no utiliza una barra inversa para escapar ese apóstrofo.

Comprueba las reglas de comparación

Una intercalación controla la igualdad y la ordenación del texto, incluidas las mayúsculas, las minúsculas y las letras con tilde. En las comparaciones habituales de SQLite y PostgreSQL utilizadas aquí, que distinguen mayúsculas y minúsculas, 'Chicago' y 'chicago' difieren. WHERE city = 'chicago' no devuelve filas. MySQL y SQL Server suelen utilizar intercalaciones que no distinguen mayúsculas y minúsculas, por lo que sus configuraciones habituales pueden hacer coincidir ambas formas.

Las comparaciones de intervalos de texto también siguen la intercalación. Con estos apellidos, WHERE last_name < 'M' devuelve Brown, Carter, Haddad, Kim y Lopez. Los valores se comparan desde la izquierda. Un valor más largo que empieza con los mismos caracteres viene después de su prefijo: 'Martin' va después de 'M'. Un límite de 'M' no equivale a «todos los apellidos que empiezan por M».

Pon el año primero

La columna de ejemplo hire_date almacena fechas completas como texto: año, mes y día, con longitudes fijas. Así, el orden del texto coincide con el orden del calendario.

SELECT first_name, hire_date
FROM employees
WHERE hire_date >= '2022-01-01';

Chloe, Grace y Hugo cumplen la condición. PostgreSQL también tiene un tipo DATE real que acepta este literal. Su forma estándar con tipo explícito es DATE '2022-01-01'; SQLite no utiliza esa sintaxis de literal con tipo.

Una cadena de fecha local como '03/04/2024' es ambigua en una columna de fecha porque la configuración puede hacer que signifique 4 de marzo o 3 de abril. Almacenadas como texto, las fechas con el mes primero se comparan por mes antes que por año. Por ejemplo, '12/01/2021' se ordena después de '03/15/2024' aunque la primera fecha sea anterior en el calendario.

Traduce el límite con una fecha completa

«Contratados después de 2022» significa a partir de '2023-01-01'. En cambio, comparar el texto con '2022' también incluye a Hugo, cuya fecha es '2022-08-05': el texto más largo se ordena después del prefijo coincidente.

Si una columna contiene horas, la igualdad con una fecha sola no selecciona todas las horas de ese día. Para incluir el 31 de marzo de 2024, utiliza ordered_at >= '2024-03-31' AND ordered_at < '2024-04-01'. Esto conserva todas las horas desde el inicio del 31 de marzo hasta el inicio del 1 de abril, sin incluir este último.

Una fila puede necesitar superar varias pruebas. AND exige que ambas condiciones sean verdaderas. OR exige que al menos una sea verdadera. NOT invierte verdadero y falso; cuando una condición es desconocida debido a NULL, NOT la mantiene desconocida.

Decide si deben cumplirse ambas pruebas

SELECT first_name
FROM employees
WHERE department = 'Sales' AND city = 'Chicago';

Ana y Chloe superan ambas pruebas. Emma trabaja en Sales, pero vive en Denver, así que no cumple este AND. Cambiar AND por OR también incluye a Emma, Farid y Hugo: los cinco empleados que cumplen la condición satisfacen una prueba o ambas.

Añadir una condición AND puede mantener o reducir el resultado. Añadir una condición OR puede mantenerlo o ampliarlo. Esto te permite hacer una comprobación rápida al construir un filtro por etapas.

Cada comparación debe estar completa. Escribe department = 'IT' OR department = 'Marketing', repitiendo la columna y el operador. department = 'IT' OR 'Marketing' no expresa la segunda comparación. PostgreSQL lo rechaza; SQLite trata el texto por sí solo como falso y devuelve solo el personal de IT. Del mismo modo, escribe salary > 50000 AND salary < 70000, con el salario a ambos lados de AND.

Traduce grupos de alternativas

«Empleados en Boston y Denver» suele pedir personas de cualquiera de las dos ciudades. Cada fila tiene una ciudad, así que utiliza city = 'Boston' OR city = 'Denver'. Eso devuelve Ben, David, Emma y Grace. Un AND entre estas igualdades exige que un valor de ciudad sea ambos lugares a la vez y no devuelve filas.

Cuando se mezclan operadores, NOT se evalúa antes que AND, y AND antes que OR. Sin paréntesis:

WHERE department = 'Sales'
   OR department = 'Marketing' AND city = 'Chicago'

Esto significa personal de Sales de cualquier lugar, más personal de Marketing en Chicago. Emma cumple la condición porque basta con la comparación de Sales. Para restringir ambos departamentos a Chicago, agrupa las alternativas:

SELECT first_name
FROM employees
WHERE (department = 'Sales' OR department = 'Marketing')
  AND city = 'Chicago';

Ahora cumplen la condición Ana, Chloe y Hugo. Los paréntesis hacen que las dos opciones de departamento compartan un mismo requisito de ciudad. Utilízalos para aclarar un filtro que combine AND y OR incluso cuando el orden predeterminado ya sea correcto.

Invierte un grupo completo

NOT (city = 'Chicago' OR city = 'Denver') devuelve David y Grace, de Boston. No se permite ninguna de las ciudades enumeradas. Equivale a city <> 'Chicago' AND city <> 'Denver' para estos valores.

Utilizar OR entre esas dos pruebas de desigualdad es un error habitual. Una fila de Chicago difiere de Denver y una fila de Denver difiere de Chicago. Cada empleado con una ciudad registrada supera al menos una prueba, por lo que OR no consigue excluir ninguna de las dos ciudades.

Construye una condición compleja por partes. Comprueba las filas después de la primera prueba y después de añadir la siguiente. Puedes intercambiar los dos lados de un AND o los dos lados de un OR sin cambiar la respuesta; elige la disposición que facilite más la lectura de los grupos.

Utiliza IN cuando una columna pueda coincidir con cualquier valor de una lista. Abrevia un grupo de igualdades unidas con OR sin cambiar su significado.

Construye una lista de alternativas

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing');

Ben, David, Farid y Hugo cumplen la condición. Cada uno tiene uno de los dos valores de departamento. La misma prueba podría escribirse como department = 'IT' OR department = 'Marketing'.

Pon los elementos de la lista entre paréntesis, separados por comas. Escribe el texto entre comillas y deja los valores numéricos sin ellas. Por ejemplo, employee_id IN (2, 4, 6) selecciona Ben, David y Farid. El orden de los elementos de la lista no ordena el resultado. Repetir un elemento no repite una fila coincidente: IN (6, 2, 2, 4) selecciona los mismos registros. Utiliza ORDER BY si necesitas un orden para el resultado.

IN busca coincidencias de valores completos con las mismas reglas de comparación que la igualdad. city IN ('Chi') no coincide con Chicago. Con las comparaciones habituales que distinguen mayúsculas y minúsculas utilizadas aquí, city IN ('chicago') tampoco coincide. Buscar un fragmento requiere LIKE, mientras que el comportamiento de las mayúsculas y minúsculas depende de la intercalación.

Aplica otra regla a todas las opciones

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing')
  AND city = 'Chicago';

Farid y Hugo cumplen la condición. IN es una sola condición, por lo que AND aplica la prueba de ciudad a toda la selección de departamentos. En la versión desarrollada con OR, pon paréntesis alrededor de las dos comparaciones de departamento. Sin ellos, department = 'IT' OR department = 'Marketing' AND city = 'Chicago' también incluye a Ben, porque AND tiene mayor precedencia y la regla de ciudad solo se aplica a Marketing.

Excluye los valores enumerados

WHERE city NOT IN ('Chicago', 'Denver') devuelve David y Grace. Una ciudad registrada cumple la condición solo cuando difiere de ambos elementos. Es una forma útil de expresar varias exclusiones y evita el error de unir condiciones de desigualdad con OR.

Los valores ausentes no coinciden con ninguna de las dos formas. Grace tiene un departamento NULL, así que department NOT IN ('Sales') no la incluye. La base de datos no puede establecer que el departamento ausente difiera de Sales. Para incluir también al personal sin asignar, escribe department NOT IN ('Sales') OR department IS NULL.

Un NULL dentro de una lista NOT IN crea un problema más amplio. department NOT IN ('Sales', NULL) exige tanto department <> 'Sales' como department <> NULL. La segunda comparación siempre es desconocida, por lo que la prueba combinada nunca es verdadera y WHERE no devuelve filas. Mantén las pruebas de valores ausentes separadas de la lista de valores.

Con IN, una coincidencia real sigue cumpliéndose aunque otro elemento de la lista sea NULL. department IN ('Sales', NULL) conserva a los tres empleados de Sales, pero no añade a Grace. Utiliza IS NULL para solicitar explícitamente los valores ausentes.

Una lista IN de SQL ordinario necesita al menos un elemento. PostgreSQL rechaza IN (); SQLite lo acepta como falso. Si un programa construye una lista a partir de las opciones del usuario, gestiona una lista vacía antes de enviar la consulta para controlar el comportamiento en las distintas bases de datos.

BETWEEN comprueba un intervalo con ambos extremos incluidos. Utilízalo cuando «de» y «a» incluyan los valores límite indicados; utiliza comparaciones explícitas cuando deba excluirse alguno de los límites.

Comprueba los dos extremos

SELECT name, price
FROM products
WHERE price BETWEEN 15.50 AND 89.00;

Desk Lamp, Floor Lamp, Lamp Shade y Desk Organizer cumplen la condición. Floor Lamp cuesta exactamente 89,00 y Lamp Shade exactamente 15,50, por lo que ambos se conservan. La condición significa price >= 15.50 AND price <= 89.00.

Pon primero el valor menor. price BETWEEN 89.00 AND 15.50 pide un precio de al menos 89,00 y como máximo 15,50. La sintaxis es válida, pero no hay coincidencias. BETWEEN ordinario no reordena los extremos por ti. PostgreSQL ofrece BETWEEN SYMMETRIC para hacerlo, pero utiliza la forma con el menor primero para una consulta compartida con SQLite.

Para «más de 15,50 y menos de 89,00», escribe price > 15.50 AND price < 89.00. Solo cumplen la condición Desk Lamp y Desk Organizer. Esa diferencia depende de los extremos que pide la pregunta, no de cómo se muestra el resultado.

Fuera de un intervalo

price NOT BETWEEN 20 AND 100 significa price < 20 OR price > 100. Devuelve Lamp Shade, Office Chair, Standing Desk, Desk Organizer, Bookshelf y Paper Tray. Los valores exactamente iguales a 20 o 100 estarían dentro del intervalo original y no cumplirían NOT BETWEEN.

Un valor comprobado que está ausente da desconocido en ambas pruebas. Para las existencias, BETWEEN 5 AND 40 selecciona cinco productos y NOT BETWEEN selecciona dos: Lamp Shade con 0 y Desk Organizer con 60. Bookshelf tiene existencias NULL y no pertenece a ninguno de los resultados. Por tanto, un intervalo y su negación no tienen por qué abarcar todas las filas almacenadas.

Fechas y horas

Las cadenas de fecha completas en orden YYYY-MM-DD permiten trabajar con intervalos de fechas. hire_date BETWEEN '2020-01-01' AND '2022-12-31' selecciona Ben, David y Hugo, y abarca los tres años naturales completos en esta columna que solo contiene fechas.

Una columna que contiene horas necesita otro límite superior para abarcar un mes completo. Un extremo que solo indica la fecha en una columna de marca de tiempo significa la medianoche al inicio de ese día. En texto, incluso '2024-03-31 00:00:00' se ordena después del prefijo más corto '2024-03-31'. Para incluir todas las horas de marzo, utiliza:

WHERE ordered_at >= '2024-03-01'
  AND ordered_at < '2024-04-01'

Esto incluye el inicio de marzo y termina justo antes de abril, sin tener que adivinar la última fracción de segundo del 31 de marzo.

Intervalos de texto y los dos usos de AND

Los extremos de texto son valores completos. last_name BETWEEN 'A' AND 'C' incluye Brown, pero excluye Carter, ya que Carter se ordena después de su prefijo C. Con estas reglas de texto, last_name >= 'A' AND last_name < 'D' abarca los apellidos que empiezan por A, B o C y devuelve Brown y Carter.

En price BETWEEN 10 AND 100 AND category = 'Lighting', el primer AND separa los extremos del intervalo; el segundo une la prueba del intervalo con la de categoría. Los productos coincidentes son Desk Lamp, Floor Lamp y Lamp Shade. Los saltos de línea pueden facilitar la distinción entre las dos funciones.

LIKE comprueba si un texto coincide con un patrón. Utilízalo para buscar un inicio, un final o un fragmento cuando la igualdad exigiría un valor completo exacto.

Coloca los comodines

El patrón debe coincidir con el valor completo. % puede representar cero o más caracteres, incluidos los espacios. En '%Lamp%', cualquiera de los signos de porcentaje puede coincidir con una secuencia vacía, por lo que el texto puede empezar o terminar con Lamp, además de contenerlo en medio.

_ representa exactamente un carácter. last_name LIKE '_im' encuentra Kim. Cuatro guiones bajos en first_name LIKE '____' encuentran Emma y Hugo, los nombres con exactamente cuatro letras. El guion bajo no es un carácter opcional.

SELECT first_name, phone
FROM employees
WHERE phone LIKE '312-%';

Ana, Chloe y Farid cumplen la condición porque el texto de su teléfono registrado empieza por 312-. El signo de porcentaje abarca todos los caracteres restantes.

Elige el operador y la regla de mayúsculas y minúsculas

Los comodines pertenecen a los patrones LIKE. name = '%Lamp%' busca signos de porcentaje literales y aquí no devuelve ningún producto. Los comodines de búsqueda de archivos * y ? no tienen ningún significado especial en LIKE; name LIKE 'Desk*' exige un asterisco literal después de Desk.

LIKE de SQLite normalmente no distingue mayúsculas y minúsculas para las letras ASCII de la A a la Z, mientras que LIKE ordinario de PostgreSQL sí las distingue. Por tanto, name LIKE '%desk%' encuentra Desk Lamp, Standing Desk y Desk Organizer en SQLite, pero ninguno en PostgreSQL con una intercalación que distinga mayúsculas y minúsculas. PostgreSQL también ofrece ILIKE, que no las distingue. El comportamiento de MySQL depende de la intercalación.

Para los nombres de productos ASCII utilizados aquí, LOWER(name) LIKE '%desk%' obtiene las mismas coincidencias en SQLite y PostgreSQL: LOWER convierte el nombre a minúsculas antes de buscar coincidencias. La conversión entre mayúsculas y minúsculas en otros sistemas de escritura depende de la base de datos y de las reglas del idioma. La igualdad de SQLite también difiere de su LIKE: city = 'chicago' no encuentra Chicago con la intercalación binaria predeterminada, aunque city LIKE 'chicago' sí lo encuentra.

Busca un carácter de comodín literal

Para buscar una coincidencia literal con un guion bajo, elige un carácter de escape:

WHERE code LIKE 'SPRING!_%' ESCAPE '!'

En una tabla de códigos de descuento, esto coincide con 'SPRING_10', pero no con 'SPRINGS10'. !_ es un guion bajo literal; el último % sigue coincidiendo con una secuencia. Utiliza el mismo método con !% para un signo de porcentaje literal. Escribir ESCAPE explícitamente evita depender de los valores predeterminados de la base de datos; PostgreSQL normalmente utiliza una barra inversa y SQLite no tiene un carácter de escape predeterminado.

Negación y alcance de la búsqueda

name NOT LIKE '%Lamp%' devuelve los otros cinco productos. El texto ausente no cumple ni LIKE ni NOT LIKE. De los empleados, tres teléfonos coinciden con '312-%', dos teléfonos registrados no coinciden y los tres teléfonos NULL no aparecen en ninguno de los resultados.

Un % inicial no proporciona a un índice ordinario un texto inicial fijo con el que acotar la búsqueda, por lo que puede recorrerse gran parte de la tabla. Un inicio fijo como 'Desk%' puede ayudar a un índice adecuado. Para las fechas, utiliza intervalos de fechas: LIKE funciona con estas fechas de texto, pero PostgreSQL exige una conversión antes de aplicar LIKE a una columna de tipo DATE real.

NULL marca un valor ausente: un valor puede ser desconocido, no estar registrado o no ser aplicable. Es distinto de un cero conocido o de un texto conocido sin caracteres.

Interpreta qué significa un valor ausente

Lamp Shade tiene stock = 0. Su cantidad registrada es cero, por lo que está agotado. Bookshelf tiene stock NULL: la cantidad no se registró. La base de datos no puede decirte que tiene cero unidades ni ninguna otra cantidad.

La distinción cambia la pregunta que puedes responder:

Una celda que parece vacía en una herramienta de consulta no basta para distinguir estos estados. Algunas herramientas muestran NULL como una celda vacía; otras escriben NULL. Comprueba directamente el valor almacenado.

Utiliza las pruebas de valores ausentes

SELECT first_name
FROM employees
WHERE phone IS NULL;

Ben, Emma y Hugo no tienen un teléfono registrado. IS NULL da verdadero para sus valores ausentes. Para encontrar a los cinco empleados con un teléfono registrado, utiliza phone IS NOT NULL: Ana, Chloe, David, Farid y Grace.

No escribas phone = NULL para encontrar teléfonos ausentes. Una comparación ordinaria con NULL da desconocido, incluso cuando ambos lados son NULL. WHERE conserva solo las filas verdaderas, por lo que = NULL no devuelve ninguna. <> NULL tiene el mismo problema. IS NULL comprueba el marcador de ausencia y da una respuesta definida de verdadero o falso para estos valores de una sola columna.

La forma NOT phone IS NULL también encuentra los teléfonos presentes en SQLite y PostgreSQL, pero phone IS NOT NULL facilita la lectura de la prueba deseada.

Distingue tres casos de texto

SQLite, PostgreSQL, MySQL y SQL Server distinguen la cadena vacía de NULL. phone = '' encontraría cadenas vacías, no los teléfonos ausentes de Ben, Emma o Hugo. Si una columna puede contener ambos, utiliza phone IS NULL OR phone = '' para encontrar cualquiera de los dos estados. Oracle trata una cadena vacía como NULL, por lo que esta distinción cambia al pasar a otra base de datos.

Aplica lo que indican las palabras y el esquema

«Ausente», «sin registrar» y «sin asignar» apuntan a IS NULL. department IS NULL encuentra a Grace. Que falte su departamento no significa que el texto del departamento sea la palabra 'NULL', ni permite establecer a qué departamento pertenece.

La definición de la tabla puede marcar una columna como NOT NULL, lo que significa que una fila almacenada no puede tener NULL en esa columna. Una consulta IS NULL sobre esa columna no devuelve filas. Comprueba esta regla al revisar un esquema: las columnas que permiten datos ausentes necesitan especial atención al construir exclusiones o combinar condiciones.

Una condición en SQL puede ser verdadera, falsa o desconocida. Los valores ausentes hacen necesario el tercer estado: sin una cantidad registrada, una base de datos no puede establecer si esa cantidad supera un umbral.

Una condición y su opuesta

Para Bookshelf, stock > 10 es desconocido porque sus existencias son NULL. Lo mismo ocurre con stock <= 10. WHERE conserva solo las condiciones verdaderas y descarta tanto las falsas como las desconocidas.

En la tabla de productos, stock > 10 devuelve cuatro filas y stock <= 10 devuelve tres. Juntas abarcan siete de los ocho productos. Bookshelf está ausente de ambas. Aplicar NOT no lo recupera: NOT desconocido es desconocido, por lo que NOT (stock > 10) sigue seleccionando solo las tres cantidades conocidas de como máximo 10.

Esto difiere de un valor que no cumple una condición. El cero conocido de Lamp Shade hace que stock > 10 sea falso, por lo que NOT lo convierte en verdadero. Una cantidad ausente no proporciona una comparación definida que se pueda invertir.

Combina desconocido con otra prueba

Bookshelf cuesta 120,00. En stock > 10 OR price > 100, la condición del precio es verdadera. OR solo necesita una parte verdadera, así que la fila se conserva aunque la comparación de existencias sea desconocida. En stock > 10 AND price > 100, la condición de existencias sigue sin resolverse, por lo que el resultado es desconocido y la fila se descarta.

Incluye los valores ausentes de forma deliberada

SELECT first_name
FROM employees
WHERE department <> 'Sales'
   OR department IS NULL;

Esto devuelve Ben, David, Farid, Hugo y Grace. La comparación por sí sola devolvería cuatro y dejaría fuera a Grace. La rama IS NULL incluye explícitamente al personal cuyo departamento no está asignado. Que ese personal deba contar como «fuera de Sales» depende de la respuesta que se pretende obtener; la consulta debe expresar esa decisión.

Un valor NULL en una lista NOT IN puede bloquear todo el resultado. department NOT IN ('Sales', NULL) significa que el departamento debe ser distinto de Sales y distinto de NULL. Esta última comparación es desconocida para todas las filas, por lo que la condición completa nunca es verdadera. IN sigue conservando las coincidencias reales: department IN ('Sales', NULL) selecciona a los tres empleados de Sales, pero no encuentra a Grace.

Un valor comprobado que está ausente también produce desconocido con LIKE y con un intervalo BETWEEN ordinario. IS NULL e IS NOT NULL dan respuestas definidas para estas columnas escalares. Comprueba los valores ausentes por separado con estas pruebas cuando un recuento de filas resulte sorprendente.

Comprende cuándo se agrupan los NULL

NULL = NULL sigue siendo desconocido; no se sabe si dos teléfonos ausentes son el mismo número. Sin embargo, DISTINCT trata los valores ausentes repetidos como duplicados y ORDER BY los coloca juntos. Para una comparación que trate expresamente dos NULL como iguales, SQLite y PostgreSQL también ofrecen IS NOT DISTINCT FROM.

ORDER BY establece el orden de las filas del resultado. Sin él, SQL no garantiza qué fila aparecerá primero, aunque una tabla pequeña parezca devolver siempre el mismo orden.

Elige la dirección

ASC es la opción predeterminada. ORDER BY salary y ORDER BY salary ASC solicitan la misma dirección. «Los salarios más altos primero» requiere ORDER BY salary DESC.

SELECT first_name, salary
FROM employees
ORDER BY salary DESC;

Lee el resultado de mayor a menor: Farid 83 000, Ben 71 000, Emma 65 000, David 60 000, Hugo 58 000, Ana 52 000, Chloe 48 000 y Grace 45 000. La base de datos reorganiza las filas del resultado; esta consulta no modifica la tabla almacenada.

Filtra antes de ordenar

SELECT name, price
FROM products
WHERE category = 'Lighting'
ORDER BY price;

Solo las tres filas de Lighting entran en este resultado. Sus precios ascendentes producen Lamp Shade 15,50; Desk Lamp 24,99; y después Floor Lamp 89,00. ORDER BY se escribe después de WHERE en la sentencia. Invertir esas cláusulas es un error de sintaxis.

La columna de ordenación no tiene que mostrarse. SELECT first_name FROM employees ORDER BY salary DESC; da el mismo orden de nombres sin mostrar los salarios. PostgreSQL lo restringe cuando está presente DISTINCT: una consulta DISTINCT debe seleccionar sus columnas de ordenación.

Lee el tipo de datos almacenado

Las columnas numéricas se ordenan por magnitud numérica. Las columnas de texto se ordenan por caracteres según su intercalación. Los valores de texto '10', '9' y '100' se ordenan como '10', '100', '9' con la ordenación ordinaria de caracteres. Ese orden no es numéricamente correcto, así que comprueba el tipo de columna cuando los importes parezcan desordenados.

Los valores de ejemplo de hire_date son fechas de texto completas de longitud fija con el año primero. ORDER BY hire_date empieza con Farid el 2017-09-12 y termina con Grace el 2024-02-19. DESC invierte ese orden para mostrar primero las contrataciones más recientes. Las fechas de texto con el mes primero, como MM/DD/YYYY, comparan el mes antes que el año y no pueden dar un orden cronológico fiable entre años distintos.

El orden del texto depende de la intercalación

La intercalación binaria predeterminada de SQLite coloca las letras ASCII mayúsculas antes que las minúsculas. Con esa regla, 'Zebra' precede a 'apple' y 'é' va después de 'z'. Muchas bases de datos PostgreSQL utilizan intercalaciones adaptadas al idioma que producen otro orden. Un uso uniforme de mayúsculas y minúsculas ayuda, pero las reglas de comparación de la base de datos siguen decidiendo el orden de las letras con tilde y otros caracteres.

Utiliza nombres de columna para especificar claramente la ordenación. ORDER BY 2 DESC se refiere al segundo elemento de la lista SELECT, por lo que mover columnas puede cambiar la ordenación sin avisar. ORDER BY 'salary' indica una constante de texto, no la columna de salario: SQLite no obtiene de ella una ordenación útil y PostgreSQL la rechaza. Escribe ORDER BY salary.

Una segunda columna de ordenación solo importa cuando las filas empatan en la primera. Piensa en una lista de personal ordenada: agrupa primero por ciudad y después ordena los nombres dentro de cada ciudad.

Sigue las columnas de ordenación de izquierda a derecha

SELECT last_name, city
FROM employees
ORDER BY city, last_name;

El resultado empieza con Kim y Okafor, de Boston. Después vienen Haddad, Lopez, Nguyen y O'Neill, de Chicago. Brown y Carter, de Denver, van al final. last_name no compite con city; solo decide el orden dentro de una misma ciudad.

Invertir las columnas cambia el orden principal. ORDER BY last_name, city ordena principalmente por apellido y consulta la ciudad solo cuando los apellidos empatan. Utiliza una cláusula ORDER BY con comas entre sus columnas de ordenación. Una segunda cláusula ORDER BY no es válida.

Da a cada columna su dirección

ORDER BY department, salary DESC significa departamento en orden ascendente y después salario descendente dentro de cada departamento. DESC solo corresponde al salario. Para que ambos sean descendentes, escribe department DESC, salary DESC.

Con la ordenación predeterminada de NULL en SQLite, la primera forma coloca primero el departamento ausente de Grace. Sigue IT con Farid y después Ben; Marketing tiene a David y después Hugo; Sales tiene a Emma, Ana y después Chloe. Estás leyendo una jerarquía de comparaciones, no ordenando primero todas las filas por salario para después ignorar ese orden.

Resuelve un empate con un valor único

Las filas iguales en todas las columnas de ordenación pueden aparecer en cualquier orden. ORDER BY city no resuelve qué empleado de Chicago va primero. Un orden total añade una última columna que identifica de forma única cada fila:

SELECT first_name, city
FROM employees
ORDER BY city, employee_id;

Los identificadores resuelven todos los empates de ciudad. Si los datos no cambian, esto permite que un LIMIT o una página posterior seleccione una parte reproducible de la lista ordenada. Un criterio de desempate único fija qué filas aparecen en un punto de corte; no incluye filas empatadas adicionales.

Sitúa los valores ausentes de forma deliberada

Los valores predeterminados varían según la base de datos:

Por eso, la consulta por departamento coloca a Grace al final en PostgreSQL con su configuración predeterminada, aunque la coloca al principio en SQLite. Esta diferencia es independiente de la dirección del salario.

SELECT first_name, department, salary
FROM employees
ORDER BY department NULLS LAST, salary DESC;

SQLite 3.30 o posterior, PostgreSQL y Oracle admiten NULLS FIRST y NULLS LAST. Aquí colocan a Grace después de todos los departamentos registrados y mantienen el orden de salario dentro de cada departamento. MySQL y SQL Server no aceptan esas cláusulas.

Traduce la jerarquía solicitada en la misma secuencia en que se expresa: «por departamento, con los salarios más altos primero dentro de cada departamento» da department, salary DESC. «Por orden alfabético de apellido y después de nombre» da last_name, first_name. Añade un identificador al final cuando necesites un orden reproducible entre personas con nombres idénticos.

LIMIT conserva como máximo el número elegido de filas del resultado. No decide qué filas deben ir primero. Utiliza ORDER BY para dar a una lista breve un significado como mayor salario, más reciente o más barato.

Ordena y después recorta

SELECT first_name, salary
FROM employees
ORDER BY salary DESC
LIMIT 3;

Los salarios ordenados empiezan con Farid 83 000, Ben 71 000 y Emma 65 000, así que esas tres filas se conservan. Sin ORDER BY, LIMIT 3 devuelve tres filas cualesquiera, sin garantizar que sean las de mayor salario.

WHERE actúa antes del límite. WHERE city = 'Boston' ORDER BY salary DESC LIMIT 5 devuelve solo David y Grace porque únicamente dos empleados cumplen la condición. LIMIT es un máximo, no una petición para inventar filas adicionales. LIMIT 0 no devuelve ninguna.

Omite filas para una página posterior

OFFSET omite filas antes de que LIMIT cuente las que se devolverán. ORDER BY salary DESC LIMIT 3 OFFSET 3 omite Farid, Ben y Emma, y después devuelve David, Hugo y Ana: las posiciones de la cuarta a la sexta.

Para la página k con n filas por página, omite (k − 1) × n filas. La página tres con tres filas por página utiliza LIMIT 3 OFFSET 6. Solo quedan Chloe y Grace. La primera página tiene desplazamiento cero, no uno.

«Segunda fila» y «segundo valor distinto» son peticiones diferentes. ORDER BY salary DESC LIMIT 1 OFFSET 1 devuelve aquí a Ben con 71 000. Si dos empleados compartieran el salario máximo, esa consulta devolvería a otra persona con el salario máximo. Para encontrar el segundo salario distinto, selecciona DISTINCT salary antes de ordenar y omitir filas.

Resuelve el punto de corte

ORDER BY city LIMIT 3 incluye a los dos empleados de Boston y a uno de Chicago, pero no especifica cuál de Chicago. ORDER BY city, employee_id LIMIT 3 selecciona David, Grace y Ana. El identificador único resuelve el punto de corte.

Para conservar a todos los empatados en el último valor de ordenación, PostgreSQL 13 o posterior y Oracle admiten FETCH FIRST 3 ROWS WITH TIES. Con ORDER BY city, conserva seis filas: las dos de Boston y las cuatro de Chicago. Si ORDER BY también incluye un identificador único, las filas no pueden empatar en la clave completa de ordenación.

Reconoce la sintaxis de la base de datos

SQL estándar utiliza OFFSET y FETCH, no LIMIT. PostgreSQL y Oracle aceptan OFFSET 3 ROWS FETCH FIRST 3 ROWS ONLY. SQL Server utiliza ORDER BY salary DESC OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY; ORDER BY es obligatorio para esta forma de paginación.

SQLite y MySQL también aceptan LIMIT 6, 3, con el desplazamiento primero. Utiliza preferentemente LIMIT 3 OFFSET 6 para que las funciones sean explícitas. La paginación ejecuta de nuevo una consulta para cada página. Un orden total mantiene la coherencia entre páginas mientras los datos no cambien; las inserciones o eliminaciones entre peticiones pueden seguir haciendo que las páginas repitan u omitan registros.

Las cláusulas SQL tienen un orden escrito fijo. Su orden lógico explica el resultado como una secuencia de decisiones, incluso cuando la base de datos utiliza un plan de ejecución interno diferente.

Escribe la sentencia en el orden de las cláusulas

SELECT DISTINCT city
FROM employees
WHERE department = 'Sales'
ORDER BY city
LIMIT 2 OFFSET 0;

SELECT y FROM identifican las columnas solicitadas y la tabla de origen. Las demás cláusulas son opcionales, pero, cuando aparecen, mantienen este orden: WHERE, ORDER BY, LIMIT y después OFFSET en esta forma con LIMIT. DISTINCT se sitúa justo después de SELECT.

Utiliza una cláusula WHERE con varias condiciones unidas. Un segundo WHERE es un error de sintaxis. Lo mismo se aplica a ORDER BY: pon varias columnas de ordenación en una cláusula, separadas por comas. Mover WHERE por debajo de ORDER BY no solicita otro orden de procesamiento; produce SQL no válido.

Sigue las decisiones lógicas

El resultado es Chicago y después Denver. La ciudad repetida desaparece antes de que el límite cuente las filas del resultado. No se toman dos empleados para después preguntar si viven en ciudades distintas.

El optimizador puede utilizar un plan de ejecución física diferente que produzca el mismo resultado que esta secuencia lógica.

Utiliza las columnas donde estén disponibles

WHERE comprueba las filas de origen antes de que SELECT elija las columnas que se muestran:

SELECT first_name
FROM employees
WHERE salary > 60000;

Esto funciona sin incluir el salario en la salida. Los nombres que cumplen la condición son Ben, Emma y Farid. El salario sigue siendo una columna de cada fila de origen cuando se realiza la prueba.

Del mismo modo, filtrar antes de ordenar es esencial para obtener el primer resultado dentro de un grupo:

SELECT first_name
FROM employees
WHERE department = 'Sales'
ORDER BY salary DESC
LIMIT 1;

La respuesta es Emma. Primero se selecciona al personal de Sales; después se ordenan sus salarios. Tomar primero a la persona con mayor salario de la empresa y comprobar si esa única fila pertenece a Sales no daría la respuesta buscada, porque Farid pertenece a IT.

Haz visible la estructura

Escribe una cláusula por línea y coloca las condiciones más largas en líneas separadas con sangría. Para «productos de Furniture por debajo de 200 u.m., con el precio más alto primero», utiliza:

SELECT name, price
FROM products
WHERE category = 'Furniture'
  AND price < 200
ORDER BY price DESC;

Office Chair, con 149,00, va antes que Bookshelf, con 120,00. Las dos condiciones comparten un WHERE, el umbral numérico no tiene símbolo monetario y ORDER BY ordena las filas que cumplieron las condiciones. Comprobar cada línea según su función facilita localizar tanto los errores de sintaxis como las interpretaciones incorrectas.

Antes de escribir SQL, identifica las distintas decisiones ocultas en una petición habitual. Cada decisión corresponde a una cláusula y cada cláusula puede contrastarse con la respuesta buscada.

Toma seis decisiones

1. ¿Qué tabla contiene los registros? Elige FROM.
2. ¿Qué registros cumplen los requisitos? Construye WHERE.
3. ¿Qué campos responden a la pregunta? Elige SELECT.
4. ¿Son útiles los valores repetidos en el resultado? Decide si usar DISTINCT.
5. ¿Qué debe ir primero? Construye ORDER BY.
6. ¿Hay un máximo o una página? Añade LIMIT y OFFSET.

Para «al menos», incluye la igualdad. «Uno de» sugiere IN, «contiene» sugiere un patrón LIKE con signos de porcentaje en ambos extremos, «ausente» sugiere IS NULL y «valores distintos» sugiere DISTINCT. Una petición de las primeras n filas necesita tanto una dirección de ordenación como un límite.

Construye una lista breve de personal

«Muestra los nombres y las fechas de contratación de los tres empleados contratados más recientemente fuera de Sales que tengan un teléfono registrado, con los más recientes primero». Incluye al personal sin asignar en el significado de «fuera de Sales» de esta petición.

Empieza con los empleados. La regla de departamento es department <> 'Sales' OR department IS NULL. Agrupa esa elección para que la regla del teléfono se aplique a ambas ramas. Muestra los nombres y las fechas y después ordena las filas que cumplen las condiciones:

SELECT first_name, last_name, hire_date
FROM employees
WHERE (department <> 'Sales' OR department IS NULL)
  AND phone IS NOT NULL
ORDER BY hire_date DESC
LIMIT 3;

Grace Okafor, con fecha 2024-02-19, va primero; David Kim, con 2020-11-23, segundo; y Farid Haddad, con 2017-09-12, tercero. Eliminar la rama IS NULL deja fuera a Grace y mantiene solo dos resultados. Ante una petición poco clara, decide cómo deben contar los departamentos ausentes e indica la decisión junto con la respuesta.

Combina categoría, precio y existencias

«¿Qué productos de Lighting o Storage cuestan menos de 20 u.m. y tienen existencias, con los más baratos primero?». Utiliza IN para las dos opciones de categoría y exige una cantidad positiva conocida:

SELECT name, price
FROM products
WHERE category IN ('Lighting', 'Storage')
  AND price < 20
  AND stock > 0
ORDER BY price;

Paper Tray, con 9,99, va antes que Desk Organizer, con 18,75. Lamp Shade es lo bastante barato y pertenece a una categoría elegida, pero sus existencias son cero, así que no supera la última prueba. Una cantidad de existencias ausente tampoco la superaría porque no permite establecer que sea positiva.

Comprueba las filas que podrían revelar un error

Empieza con SELECT * FROM products LIMIT 5; al explorar el esquema y unos pocos registros. Añade los filtros uno a uno, comprueba los cambios en el recuento del resultado y muestra temporalmente las columnas evaluadas cuando resulte útil.

Comprueba los límites exactos, los valores ausentes, las mayúsculas y minúsculas del texto y los empates en el límite. NOT muestra las filas donde una condición era falsa; no revela aquellas donde era desconocida. Ejecuta pruebas IS NULL por separado. Comprueba que la salida tenga las columnas solicitadas y que ORDER BY resuelva los empates que afecten a la respuesta.

Al trasladar la consulta a otra base de datos, comprueba la sintaxis de limitación de filas, las reglas de mayúsculas y minúsculas de la igualdad y LIKE, las comillas de identificadores, el tratamiento de fechas y la posición de NULL. Los ejemplos utilizan LIMIT en SQLite y PostgreSQL; la forma de SQL estándar para limitar filas es OFFSET con FETCH FIRST.