Vissa människor går långt för att undvika GROUP BY och HAVING-klausuler i sina frågor. Felmeddelandena är kinkiga men de är oftast rätt. GROUP BY och ATT HA nyckelord är avgörande för bra SQL-rapportering.
Det primära skälet till GROUP BY är att minska antalet rader, vanligtvis genom aggregering. Den producerar endast en rad för varje matchande gruppering från indata. Detta gör att du kan göra sofistikerade beräkningar via vanlig SQL.
Exempel på frukt:
Vi har lite frukt:
Detta nästa fall tillåter oss att se framåt. Mitt på året, vilka frukter kommer att finnas tillgängliga? Vi gör detta med samma fråga som ovan, men efter att frågan har körts kontrollerar vi värdena för min(fresh_until) genom att använda en having-sats. HA är hur du kvalificerar ett aggregat.
Alla äpplen och druvor kommer att finnas tillgängliga mitt på året.
Listan över objekt mellan SELECT och FROM, mållistan. kan innehålla icke-aggregat och aggregat. Dessa icke-aggregerade kolumner i mållistan
ska vara i gruppen för klausul. Felmeddelandet säger det. Ordningen på kolumnerna i gruppen för klausul spelar roll. Det avgör hur aggregaten grupperas. Ordningen är ofta hierarkisk. Vad det betyder för dina kolumner är ditt fokus. Det kan vara frukt, eller källor och/eller färsk_till datum.
Exempel på spelkort
Låt oss titta på en annan uppsättning exempel som illustrerar att extrahera information om spelkort. Du kan lära dig mer om kort på Wikipedias standardkort.
Anta att du programmässigt delar ut sex 5-kortshänder, som sex personer som spelar poker. Totalt 30 kort används i denna affär. De är i hand tabell som följande där namnen på kort och färger sammanfogas av uppslagstabeller. Vi lagrar led så att vi kan sortera ordentligt. Vi använder namn för visning. Namnen och rangen har ett förhållande mellan ett och ett för vart och ett av kort och färger.
Vad är antalet färger för varje hand? Vi bryr oss egentligen bara om händer som har 3 eller fler kort i samma färg. Det kommer att berätta för oss vem som har bättre chanser till en pokerspolning. Observera att även om GROUP BY verkar antyda ORDER BY, så gör det inte det. BESTÄLLNING AV måste vara explicit.
Så vad händer om du grupperade din fråga fel? Om denna hand bordet är inte grupperat efter handid, då får du 30 poster med 6 händer med 5-kort. Om du hade aggregat skulle de grupperas efter rad. Inte särskilt användbart.
Om du aggregerar kortnamnet och inte tar med
kortnamnet solo på mållistan och försöker beställa efter kortnamn,
får du felmeddelandet att det inte ska finnas i
ordning efter klausul. Order by-satsen bör innehålla
element från group by-satsen.
Om kortets namn uttryckligen finns i mållistan,
då måste kortets namn finnas i gruppen för klausul och
därför tillåtet i ordningsförslaget.
Om frågan är i färg kommer det att finnas minst 1 eller max 4 poster per färg för var och en av de sex händerna. Lägg märke till att vi sorterar efter färgrang som
också måste finnas i gruppen efter klausul. su_name och su_rank har en en till en relation.
För att se fördelningen av kort i händer måste vi gruppera efter kortrankningskolumnen. Naturligtvis finns det fyra färger av varje kort, så du kommer inte att se ett kort på fler än fyra händer.
För att kika och se vem som har ess kan vi använda följande korta fråga. Observera att det finns en WHERE-sats som körs när raderna samlas in. HAVING exekveras efter att raderna har samlats in.
Sammanfattning
Dessa exempel är enkla sätt att utvärdera kända enheter. Experimentera och använd dessa enkla regler.
- Om en kolumn finns på mållistan och inte ett aggregat måste den finnas i en GROUP BY-sats.
- WHERE-satser förekommer under urvalsprocessen.
- HAVING-satser uppstår efter att aggregaten har slutförts.
- Endast icke-aggregator kan finnas i ORDER BY-satsen.
- Ordningen av GROUP BY-klausulen är viktig.