Hasta ahora hemos aprendido a seleccionar columnas y a filtrar filas. Ahora vamos aprender a ordenar los resultados que obtenemos.
Sin ya has estado jugueteando con los artículos anteriores, algo que probablemente hayas notado es que los resultados a veces salen “ordenados como quieren”.
Aquí hay un concepto teórico fundamental que entender. Las tablas en una base de datos relacional representan conjuntos matemáticos, y los conjuntos NO tienen orden.
Aunque muchas veces veas que los datos salen ordenados por la clave primaria, nunca debes confiar en ese orden por defecto.
Si el motor de base de datos decide usar un índice diferente, o paralelizar la consulta, el orden cambiará.
La única forma de garantizar que los datos se devuelvan ordenados es utilizando explícitamente la cláusula ORDER BY.
Sintaxis básica
La cláusula ORDER BY se coloca al final de nuestra sentencia SELECT.
La sintaxis básica de ORDER BY es la siguiente:
SELECT columnas
FROM tabla
ORDER BY columna1 [ASC|DESC], columna2 [ASC|DESC], ...;
- columnas: Las columnas que deseas seleccionar en la consulta.
- tabla: La tabla de la cual se están seleccionando los datos.
- columna1, columna2, …: Las columnas por las cuales deseas ordenar los resultados.
- ASC|DESC: Especifica si el orden es ascendente (
ASC, por defecto) o descendente (DESC).
Por ejemplo
-- Ordenar clientes por apellido alfabéticamente (A-Z)
SELECT Nombre, Apellido
FROM Clientes
WHERE Ciudad = 'Madrid'
ORDER BY Apellido ASC;
-- Ordenar productos del más caro al más barato
SELECT Nombre, Precio
FROM Productos
ORDER BY Precio DESC;
Ordenación por múltiples columnas
En el mundo real, ordenar por una sola columna rara vez es suficiente. Imagina que ordenas a tus usuarios por Apellido.
Si tienes 50 personas que se apellidan “García”, ¿en qué orden salen “los Garcías”?
De nuevo, aleatorio (entre ellos).
Para solucionar esto, podemos especificar múltiples columnas separadas por comas. SQL Server ordenará por la primera; si hay empates, usará la segunda para desempatar, y así sucesivamente.
SELECT Apellido, Nombre, FechaRegistro
FROM Usuarios
ORDER BY Apellido ASC, Nombre ASC;
En este ejemplo:
- Primero agrupa a todos los “García”, luego “Gómez”, etc.
- Dentro del grupo de los “García”, ordena por
Nombre(Ana, Benito, Carlos…).
Puedes mezclar direcciones. Podrías querer ordenar por Departamento ascendente, pero dentro de cada departamento, mostrar los empleados con Salario descendente (los que más cobran primero).
ORDER BY Departamento ASC, Salario DESC
¿Qué pasa con los NULOS?
Si ordenamos una columna que tiene valores NULL, ¿dónde se colocan? ¿Al principio o al final?
En SQL Server, los valores NULL se consideran los valores más bajos posibles.
- Si ordenas ASC: Los NULL aparecerán primero.
- Si ordenas DESC: Los NULL aparecerán al final.
Si necesitas una lógica diferente (por ejemplo, quieres ordenar ascendente pero que los nulos salgan al final), tendrás que usar trucos con funciones como ISNULL o expresiones CASE, que veremos más adelante.
Ordenar por posición
Es posible que en código antiguo veáis algo así:
SELECT Nombre, Apellido, Email
FROM Clientes
ORDER BY 2, 1;
Esto significa: Ordena por la columna 2 (Apellido) y luego por la 1 (Nombre)”
Aunque T-SQL lo permite, pero no hagas eso. Es código pocho. Usad siempre el nombre de la columna.
Si mañana alguien cambia el SELECT y añade una columna al principio, tu ORDER BY 2 pasará a ordenar por una columna diferente sin que te des cuenta, rompiendo la lógica de la aplicación.
Rendimiento: El coste de ordenar
Ordenar es una de las operaciones más costosas para una base de datos. Requiere CPU y memoria para comparar y reorganizar los datos.
Si ordenas millones de registros sin tener un índice adecuado, verás cómo tu consulta se atasca.
- Si la columna por la que ordenas tiene un Índice, SQL Server puede devolver los datos instantáneamente porque ya están ordenados físicamente o en el árbol del índice.
- Si no tiene índice, SQL Server tendrá que hacer una operación de
Sorten memoria lo cual es lento.
Por eso, como regla general ordena solo si es estrictamente necesario para la presentación final de los datos.
