Algumas pessoas fazem um grande esforço para evitar as cláusulas GROUP BY e HAVING em suas consultas. As mensagens de erro são complicadas, mas geralmente estão certas. As palavras-chave GROUP BY e HAVING são essenciais para um bom relatório SQL.
A principal razão para GROUP BY é reduzir o número de linhas, geralmente por agregação. Ele produz apenas uma linha para cada agrupamento correspondente da entrada. Isso permite que você faça cálculos sofisticados via SQL comum.
Exemplo de frutas:
Temos algumas frutas:
Este próximo caso nos permite olhar para frente. No meio do ano, quais frutas estarão disponíveis? Fazemos isso com a mesma consulta acima, no entanto, após a execução da consulta, verificamos os valores de min(fresh_until) usando uma cláusula having. TER é como você qualifica um agregado.
Todas as maçãs e uvas estarão disponíveis no meio do ano.
A lista de itens entre SELECT e FROM, a lista de destino. pode conter não agregados e agregados. Essas colunas não agregadas na lista de destino
devem estar na cláusula group by. A mensagem de erro diz isso. A ordem das colunas no grupo por cláusula é importante. Ele determina como os agregados são agrupados. A ordem é muitas vezes hierárquica. O que isso significa para suas colunas é o seu foco. Pode ser fruta, ou fontes e/ou fresh_until date.
Exemplos de cartas de baralho
Vejamos outro conjunto de exemplos que ilustram a extração de informações sobre cartas de baralho. Você pode saber mais sobre cartões nos cartões padrão da Wikipedia.
Suponha que você distribua programaticamente seis mãos de 5 cartas, como seis pessoas jogando pôquer. Um total de 30 cartões são usados neste negócio. Eles estão em uma mão tabela como a seguinte, onde os nomes das cartas e naipes são unidos por tabelas de consulta. Armazenamos as classificações para que possamos classificar corretamente. Usamos nomes para exibição. Os nomes e classificações têm uma relação de um para um para cada uma das cartas e naipes.
Qual é a contagem de naipes para cada mão? Nós realmente só nos importamos com qualquer mão que tenha 3 ou mais cartas do mesmo naipe. Isso nos dirá quem tem melhores chances de um poker flush. Observe que, embora GROUP BY pareça implicar ORDER BY, isso não acontece. ORDER BY deve ser explícito.
E daí se você tiver agrupado incorretamente sua consulta? Se esta mão mesa não é agrupada por handid, então você receberá 30 registros de 6 mãos de 5 cartas. Se você tivesse agregados, eles seriam agrupados por linha. Não muito útil.
Se você agregar o nome do cartão e não incluir
o nome do cartão sozinho na lista de destino e tentar ordenar pelo nome do cartão,
você receberá a mensagem de erro de que ele não deveria estar
a ordem por cláusula. A cláusula order by deve conter
elementos da cláusula group by.
No entanto, se o nome do cartão estiver explicitamente na lista de destino,
então o nome do cartão deve estar na cláusula group by e
portanto, permitido na cláusula order by.
Se a consulta for por naipe, haverá no mínimo 1 ou no máximo 4 registros por naipe para cada uma das seis mãos. Observe que estamos classificando por naipe que
também deve estar na cláusula group by. su_name e su_rank têm um relacionamento de um para um.
Para ver a distribuição das cartas nas mãos, devemos agrupar pela coluna de classificação das cartas. Claro que existem 4 naipes de cada carta, então você não verá uma carta em mais de quatro mãos.
Para espiar e ver quem está segurando ases, podemos usar a seguinte consulta curta. Observe que há uma cláusula WHERE que é executada durante a coleta das linhas. HAVING é executado depois que as linhas são coletadas.
Resumo
Esses exemplos são maneiras simples de avaliar entidades conhecidas. Experimente e use essas regras simples.
- Se uma coluna estiver na lista de destino e não em um agregado, ela deverá estar em uma cláusula GROUP BY.
- Cláusulas WHERE ocorrem durante o processo de seleção.
- As cláusulas HAVING ocorrem após a conclusão das agregações.
- Somente não agregados podem estar na cláusula ORDER BY.
- A ordem da cláusula GROUP BY é importante.
