Las funciones de agregación no pueden aparecer en el where

Es habitual encontrarse consultas como la siguiente: hallar los artículos con el precio más bajo de entre los contenidos en una tabla. Para resolverla podríamos tener la tentación de ejecutar un select SQL, que incluye funciones de agregación en el where, y, por tanto, es incorrecta:

Ejercicio típico: entidades que se relacionan con dos (o más) entidades de otro tipo

Un tipo de consulta habitual es la que pretende obtener datos de una entidad de un tipo dado (entidad A) que se relacionan con varias (dos o más) de otra entidad de otro tipo (entidad B). P.ej.: alumnos (A) que están matriculados en dos asignaturas (B) dadas, proyectos (A) en los que trabajan al mismo tiempo dos empleados (B) dados, etc.

Todo lo que esté en el having, y que no sean funciones de agregación, debe estar en el group by

En otra lección de este blog (que debes leer aquí antes que ésta) se discute sobre la regla de SQL que obliga a que, en una consulta de agrupación, si se quiere recuperar en el select algún dato (o expresión que use algún dato) que no sea el resultado de una función de agregación, ese dato debe estar en el criterio de agrupación de la cláusula group by. Esa regla también se aplica a la cláusula having: ésta solo puede tener funciones de agregación o campos del criterio de agrupación.

Todo lo que esté en el select, y que no sean funciones de agregación, debe estar en el group by

Cuando se hace una consulta de agrupación, SQL obliga a que todo aquello que se incluya en el select sea alguna de estas tres cosas:

• campos del criterio de agrupación
• expresiones que usen campos del criterio de agrupación
• expresiones con funciones de agregación

En esta lección discutimos sobre esta regla de SQL.

Agrupar preferentemente incluyendo campos clave

Aunque no se pida explícitamente, siempre es más correcto, porque evita potenciales errores, incluir campos clave en el criterio de agrupación, además de los necesarios por estar incluidos en el select o having.

Pensar bien si hay que contar con distinct o sin él

Contar parece fácil. Pero hay que asegurarse de que no se cuentan valores repetidos, salvo que sea necesario. Este es un fallo frecuente. Lo estudiamos con unos sencillos ejemplos. 

No hace falta usar coalesce con count

En algunos ejemplos de agrupaciones, por ejemplo sobre el resultado de un outer join, hemos usado coalesce para evitar que aparezca un valor null como resultado de alguna función de agrupación sobre un grupo de valores que son todos nulos. 

Por ejemplo: la expresión sum(salario) devuelve null si todos los valores del campo salario en el grupo son null; pero coalesce(sum(salario), 0) devuelve 0.

Lo anterior no es necesario si la función de agrupación es count. La función count ya devuelve 0 si todos los valores contados son null. 

No usar group by en vez de select distinct

Cuando se trata de encontrar resultados sin repetidos, puedes estar tentado de usar group by en vez de select distinct. Aquí te explicamos por qué no debes hacerlo.