Cláusulas Care To Know:todo sobre SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY y LIMIT

SQL es un lenguaje de bases de datos y PostgreSQL es nuestro elegido. A menudo, el almacenamiento de datos es solo una faceta del proceso. Por lo general, en cualquier esfuerzo centrado en datos, usted:verá y leerá datos, tomará medidas o implementará cambios en los datos, recopilará información para la toma de decisiones (análisis) o manipulará los datos almacenados de alguna forma o manera.

SQL se compone de una combinación de palabras clave, comandos y cláusulas. SQL parece simple. Solo unos pocos 'fáciles ' comandos aquí y allá. No es gran cosa, ¿verdad?

Pero, hay más en SQL de lo que parece. SQL puede hacerte tropezar con esos 'fáciles ' consultas.

Un desafío (que debo revisar de forma rutinaria) es comprender que el orden de ejecución de SQL es definitivamente diferente al de su sintaxis.

En esta publicación de blog, visito, a alto nivel, las principales cláusulas de SQL según se aplican a PostgreSQL. Hay muchos dialectos de SQL, pero la interpretación de PostgreSQL es el enfoque aquí. (Algunas características de cada cláusula pueden aplicarse muy bien a otros dialectos de SQL).

Las cláusulas SQL forman la base de los comandos y consultas básicos que se usan con frecuencia. Dicho esto, las consultas avanzadas y los ejemplos que utilizan funciones de ventana, CTE, tablas derivadas, etc. no se tratarán en esta publicación.

Como veremos, no todas las cláusulas son iguales. Sin embargo, funcionan en tándem, proporcionando resultados de consulta sin problemas (o no).

Permítanme aclarar...

Periódicamente mencionaré una orden de ejecución a lo largo de la publicación del blog, ya que se aplica a muchas de las cláusulas. Pero, esto es generalizado.

Según tengo entendido, la mayoría de las veces, el optimizador elige y decide el mejor plan de consulta para su ejecución.

SELECT:la cláusula 'quisquillosa' utilizada para consultar la base de datos

SELECT es una cláusula ocupada. Está en todas partes. Se usa más que todas las demás cláusulas. Ciertas cláusulas que puede no necesitar en absoluto. No es tanto el caso con SELECT, ya que es una cláusula obligatoria.

La cláusula SELECT se usa normalmente para consultar la base de datos y contiene (en un nivel básico):

1. Una lista SELECT:las columnas de datos que desea.
2. los conjuntos de datos de origen, nombrados en la cláusula FROM. Tablas, vistas, CTE, etc. Aquí es de donde provienen los datos.
3. una cláusula WHERE opcional utilizada para filtrar filas proporcionadas por la cláusula FROM.

(Las cláusulas FROM y WHERE se analizarán en sus respectivas secciones).

En verdad, diría que se requiere la cláusula SELECT en PostgreSQL para recuperar cualquier cosa. Pero luego, existe el comando TABLE que devuelve todas las filas y columnas de una tabla.

Sin embargo, hay una separación entre los dos. SELECT puede especificar columnas individuales, pero con el comando TABLE, se devuelven todas las columnas.

SELECCIONE destacados:

• SELECT * es una notación abreviada y devuelve todas las columnas de las fuentes de datos.
• Aunque SELECT se nombra en términos de sintaxis como la primera cláusula (con la excepción de aquellas consultas que usan una cláusula WITH:no se analiza aquí), no se ejecuta primero. En particular, SELECT tampoco es la última cláusula en ejecutarse.
• A una expresión (o cualquier columna) se le puede dar un nombre de referencia o ALIAS en la cláusula SELECT, con una advertencia. Esos nombres dados se pueden usar en las cláusulas ORDER BY y GROUP BY, pero no en las cláusulas WHERE o HAVING.
• Cuando una cláusula GROUP BY está presente (o funciones agregadas) en la consulta, SELECT no debe nombrar ninguna columna sin agrupar. Solo aquellas columnas en cualquier función agregada o aquellas funcionalmente dependientes de las columnas agrupadas.
• SELECCIONAR no solo devuelve columnas específicas, sino que su uso también se extiende a las declaraciones INSERT y CREATE TABLE.
• La cláusula SELECT está lejos de ser simple.

Consulte la sección de documentación de la cláusula SELECT oficial de PostgreSQL para obtener una cobertura detallada.

FROM:proporciona las fuentes de datos para la consulta

FROM es principalmente una cláusula obligatoria. Llamo a esto 'vagamente ' debido al comando TABLE disponible (mencionado anteriormente), que no requiere la cláusula FROM.

Por otra parte, puede seleccionar expresiones arbitrarias, sin tabla con nombre en una consulta SELECT. Sin embargo, con TABLE, eso no es posible.

Aquí hay un ejemplo en psql:

learning=> SELECT 2+2;
?column? 
----------
4
(1 row)

Pero con TABLA:

learning=> TABLE 2+2;
ERROR: syntax error at or near "2"
LINE 1: TABLE 2+2;
^

Algunos dialectos de SQL incluso permiten nombrar una tabla inexistente para mitigar el hecho de no tener una tabla real en la cláusula FROM. Sin embargo, en PostgreSQL, como puede ver en la consulta simple anterior, no es obligatorio.

Pero, si necesita que se devuelvan datos almacenados reales además de expresiones simples, necesitará la cláusula FROM. Sin él, no hay datos para operar.

Por lo tanto, FROM es absolutamente necesario para consultar cualquier tabla.

En Postgres, todas las tablas nombradas en la cláusula FROM primero se unen de forma cruzada (si no está presente una cláusula WITH) en el orden de ejecución que establece un producto cartesiano. Esto tiene sentido ya que necesitamos datos para trabajar.

La documentación FROM aquí también señala que, por lo general, este conjunto de datos se reduce a un pequeño número de filas a través de una condición de cláusula WHERE presente.

La cláusula FROM acepta una serie de elementos específicos. Estos son solo algunos (consulte la documentación de enlace a continuación para ver la lista completa):

• Nombre de la tabla (obviamente lo necesitamos).
• UNA VISTA.
• Una instrucción SELECT (una subconsulta).
• Nombre CTE (Cláusula CON).
• Tipo de JOIN - si lo hay.
• Una función (no estaba al tanto de esto. ¡Qué genial!)

DESDE destacados:

• Aunque FROM aparece sintácticamente como la segunda cláusula en una consulta SELECT, se ejecuta primero.
• FROM proporciona (al cargar) todas las filas de cualquier tabla (real o virtual) nombrada en su cláusula.
• Los nombres de las tablas pueden tener un alias en la cláusula FROM (por ejemplo, FROM shoe AS s), pero ese ALIAS debe hacer referencia a ellos a lo largo de la consulta en el futuro.
• FROM es una cláusula obligatoria al consultar tablas.

Consulte la sección oficial de la cláusula FROM de PostgreSQL para obtener una cobertura detallada.

WHERE:filtra las filas de las fuentes de datos en función de las expresiones condicionales de validación booleana

WHERE es una cláusula opcional. Sin embargo, cuando está presente en una consulta, su deber es eliminar los registros provistos por la cláusula FROM que no pasan su verificación condicional booleana.

La cláusula WHERE también tiene un uso profundo con otros comandos SQL además de SELECT. Es decir, comandos DML como INSERTAR (no directamente, sino a través de SELECCIONAR), ACTUALIZAR y ELIMINAR.

De hecho, sin una cláusula WHERE, las declaraciones UPDATE y DELETE probablemente afectarían a todas las filas de destino. Tal vez no sea lo que pretendías (¡Ay!).

Las funciones agregadas no se pueden usar en la expresión condicional booleana de la cláusula WHERE. Todavía no se ha producido ningún agrupamiento en el orden de ejecución. Por lo tanto, los agregados no están disponibles (todavía) para la cláusula WHERE.

DONDE la evaluación se basa en una comprobación booleana utilizando cualquiera de los operadores de comparación. (Por ejemplo,>, <, =, <>, etc…)

La cláusula WHERE no puede acceder a los nombres de columna con alias enumerados en la cláusula SELECT. Dado que la cláusula SELECT es realmente (no en cuanto a la sintaxis) ejecutado después de la cláusula WHERE, esas columnas con alias aún no están disponibles.

DONDE destaca:

• Las funciones agregadas no son accesibles y no se pueden usar en la verificación condicional booleana de una cláusula WHERE. (La cláusula WHERE posiblemente sea responsable de que se proporcionen filas para agregar funciones y agrupar para el cálculo).
• No se puede hacer referencia a las columnas con alias en la cláusula SELECT en la cláusula WHERE.
• La verificación condicional de la expresión booleana de la cláusula WHERE puede dar como resultado:verdadero, falso o NULL.
• Se eliminan todas las filas en las que la expresión booleana de la cláusula WHERE se evalúa como falsa o NULL.
• Se pueden verificar varias condiciones booleanas en la cláusula WHERE aprovechando las palabras clave AND u OR.

Consulte la sección de la cláusula WHERE oficial de PostgreSQL para obtener una cobertura detallada.

GROUP BY - Grupos de formularios

Es una cláusula opcional.

Esta cláusula crea una sola fila para los seleccionados, que contiene una coincidencia en el valor de la columna agrupada especificada.

GROUP BY puede ser complicado, por lo tanto, creo que es pertinente incluir este pasaje de la documentación:

"Cuando GROUP BY está presente, o cualquier función agregada está presente, no es válido que las expresiones de lista SELECT se refieran a columnas no agrupadas excepto dentro de funciones agregadas o cuando la columna no agrupada depende funcionalmente de las columnas agrupadas, ya que de lo contrario habría más de un valor posible para devolver para una columna sin agrupar. Existe una dependencia funcional si las columnas agrupadas (o un subconjunto de las mismas) son la clave principal de la tabla que contiene la columna sin agrupar".

AGRUPADO POR destacados:

• Postgres permite agrupar no solo las columnas de la tabla de origen, sino también las que aparecen en la lista de columnas SELECT. Esto es ligeramente diferente de SQL estricto.
• En determinadas consultas, GROUP BY puede imitar la cláusula DISTINCT eliminando los valores duplicados de la columna de la cláusula SELECT.
• El orden de las columnas es irrelevante para GROUP BY.
• Las columnas a las que no se dirige la cláusula GROUP BY no se pueden referenciar excepto en agregados.
• En muchos casos, puede agrupar en una CLAVE PRINCIPAL para aquellas columnas funcionalmente dependientes de esa clave.
• La agrupación todavía se realiza para consultas que utilizan funciones agregadas en ausencia de una cláusula GROUP BY.

Consulte la sección de la cláusula GROUP BY oficial de PostgreSQL para obtener una cobertura detallada.

HAVING:filtros GROUP BY columna(s) y funciones agregadas

Es una cláusula opcional.

HAVING filtra filas del conjunto de resultados con una verificación condicional booleana al igual que la cláusula WHERE, excepto que filtra las filas formadas por la cláusula GROUP BY y/o funciones agregadas.

TENER destacados:

• La cláusula HAVING puede hacer referencia a las columnas nombradas en funciones agregadas (incluso aquellas que no están agrupadas) además de cualquier columna GROUP BY.
• HAVING es responsable de eliminar filas después de aplicar funciones agregadas o agrupación.
• Puede hacer referencia a columnas no agregadas en la cláusula HAVING, aunque hacerlo tiene muy poca utilidad.
• Aunque la cláusula HAVING se usa muchas veces junto con la cláusula GROUP BY, puede usarla sola. Los resultados de la consulta se forman en un solo grupo de esas columnas solo en funciones agregadas.

Consulte la sección de la cláusula oficial HAVING de PostgreSQL para obtener una cobertura detallada.

ORDENAR POR - Una medida de orden a partir de la aleatoriedad

Es una cláusula opcional.

Utilice ORDER BY cuando necesite un pedido específico. De lo contrario, la base de datos puede (y lo hará) devolver resultados en cualquier orden arbitrario.

Incluso si los resultados parecen estar en orden, esto no está garantizado.

No se deje engañar. Utilice ORDENAR POR.

Hay dos patrones de pedido disponibles. Orden ASC (ascendente) o DESC (descendente), siendo ASC el predeterminado.

Si su conjunto de resultados debe incluir valores NULL, también se pueden usar en el orden de la siguiente manera:especificar NULLS LAST hace que (NULLs) se clasifiquen después de los no NULL, mientras que solicitar NULLS FIRST es lo contrario.

ORDENAR POR destacados:

• Las expresiones de clasificación son cualquiera de las que estarían permitidas en la lista SELECT de la consulta.
• PostgreSQL le permite ORDENAR POR columnas que no están presentes en la cláusula SELECT donde algunos dialectos de SQL no lo hacen.
• Los resultados de las consultas son caprichosos y no se garantiza que se parezcan a ningún patrón u orden a menos que se use una cláusula ORDER BY.
• ORDER BY y la cláusula LIMIT (ver la siguiente sección), son excelentes combinados para determinar un 'Superior ' conjunto de resultados de filas. (por ejemplo, 5 días de mayor venta, 5 pares de zapatos de menor venta, mejor vendedor este trimestre)
• Puede ordenar los resultados por número de posición de columna en la lista SELECT, pero el número especificado no debe ser mayor que el número de elementos en dicha lista de cláusulas SELECT. En otras palabras, si la cláusula SELECT tiene solo 2 elementos, ORDER BY 3 generará un error.
• Cada expresión individual solo se ordena por su opción enumerada. (por ejemplo, ORDER BY col_1 DESC, col_2 DESC no es lo mismo que ORDER BY col_1, col_2 DESC)

Consulte la sección de la cláusula ORDER BY oficial de PostgreSQL para obtener una cobertura detallada.

LIMIT:recuperar un número específico de filas de los resultados de la consulta

LIMIT es una cláusula opcional.

LIMIT en realidad consta de 2 subcláusulas, siendo OFFSET la segunda de ellas.

Si se proporciona un valor para la parte de DESPLAZAMIENTO de la cláusula, las filas del conjunto de resultados se devuelven después omitiendo ese número de filas.

Una sección importante en la documentación a tener en cuenta:

"El planificador de consultas tiene en cuenta LIMIT al generar un plan de consulta, por lo que es muy probable que obtenga diferentes planes (que produzcan diferentes órdenes de fila) según lo que use para LIMIT y OFFSET. Por lo tanto, usar diferentes valores de LIMIT/OFFSET para seleccionar diferentes los subconjuntos del resultado de una consulta darán resultados inconsistentes a menos que aplique un orden de resultados predecible con ORDER BY. Esto no es un error; es una consecuencia inherente del hecho de que SQL no promete entregar los resultados de una consulta en ningún orden en particular. a menos que se use ORDER BY para restringir el orden".

LÍMITE de destacados:

• LIMIT posiblemente puede devolver menos filas que el número definido si la consulta en sí produce menos filas en el conjunto de resultados. En otras palabras, no tendría ningún impacto en la cantidad de filas devueltas.
• La sintaxis LIMIT ALL es aceptable y tiene el mismo efecto que no incluir una cláusula LIMIT en absoluto.
• Aunque se omiten 'x' número de filas debido a una cláusula OFFSET, esta no es una 'solución alternativa ' para cualquier ganancia de rendimiento, ya que todavía se calculan para el plan de consulta en el servidor.
• OFFSET 0 es equivalente a no incluir una cláusula OFFSET en absoluto.

Consulte la sección Cláusula LIMIT oficial de PostgreSQL para obtener una cobertura detallada.

La interpretación de PostgreSQL de las principales cláusulas de SQL es propia. Independientemente de cómo PostgreSQL elija implementarlos o no, son fundamentales para las consultas SQL y la familiaridad con sus características individuales (y matices) solo puede beneficiar a los usuarios en el futuro.

Si bien se han escrito volúmenes de artículos, libros, documentación y publicaciones de blog sobre cada una de estas cláusulas, espero que encuentre esta descripción general de alto nivel digerible e informativa.

Gracias por leer.