Nogle mennesker går meget langt for at undgå GROUP BY og HAVING-klausuler i deres forespørgsler. Fejlmeddelelserne er nøjeregnende, men de er normalt rigtige. GRUPPER EFTER og AT HAVE nøgleord er afgørende for god SQL-rapportering.
Den primære årsag til GROUP BY er at reducere antallet af rækker, normalt ved aggregering. Den producerer kun én række for hver matchende gruppering fra inputtet. Dette giver dig mulighed for at lave sofistikerede beregninger via almindelig SQL.
Frugteksempel:
Vi har noget frugt:
Denne næste sag giver os mulighed for at se fremad. Midt på året, hvilke frugter vil være tilgængelige? Vi gør dette med den samme forespørgsel som ovenfor, men efter at forespørgslen er kørt, kontrollerer vi værdierne for min(fresh_until) ved at bruge en have-klausul. HAVING er, hvordan du kvalificerer et aggregat.
Alle æbler og druer vil være tilgængelige midt på året.
Listen over elementer mellem SELECT og FROM, mållisten. kan indeholde ikke-aggregater og aggregater. Disse ikke-aggregerede kolonner i mållisten
bør være i gruppe for klausul. Det siger fejlmeddelelsen. Rækkefølgen af kolonnerne i gruppen efter klausul har betydning. Det bestemmer, hvordan aggregaterne grupperes. Rækkefølgen er ofte hierarkisk. Hvad det betyder for dine kolonner er dit fokus. Det kunne være frugt eller kilder og/eller fresh_until dato.
Eksempler på spillekort
Lad os se på et andet sæt eksempler, der illustrerer udtrækning af information om spillekort. Du kan lære om kort på Wikipedia Standardkort.
Antag, at du programmæssigt deler seks 5-korts hænder, som seks personer, der spiller poker. Der bruges i alt 30 kort i denne aftale. De er i en hånd tabel som den følgende, hvor navnene på kort og kulør er sammenføjet af opslagstabeller. Vi gemmer rækker, så vi kan sortere ordentligt. Vi bruger navne til visning. Navne og rækker har en en til en relation for hvert kort og farve.
Hvad er farvetallet for hver hånd? Vi bekymrer os egentlig kun om hænder, der har 3 eller flere kort i samme kulør. Det vil fortælle os, hvem der har bedre chancer for en pokerflush. Bemærk, at selvom GROUP BY ser ud til at indebære ORDER BY, gør det det ikke. BESTIL AF skal være eksplicit.
Så hvad hvis du har grupperet din forespørgsel forkert? Hvis denne hånd bordet er ikke grupperet efter håndid, så får du 30 poster med 6 hænder på 5-kort. Hvis du havde aggregater, ville de blive grupperet efter række. Ikke særlig nyttigt.
Hvis du samler kortnavnet og ikke medtager
kortnavnet solo på mållisten og prøver at bestille efter kortnavn,
vil du modtage fejlmeddelelsen om, at det ikke skal være i
rækkefølge efter klausul. Ordren efter klausul skal indeholde
elementer af gruppe efter klausul.
Men hvis kortets navn er eksplicit i mållisten,
så skal kortnavnet være i gruppe for klausul og
derfor tilladt i rækkefølge efter klausul.
Hvis forespørgslen er efter farve, vil der være minimum 1 eller maksimum 4 poster pr. farve for hver af de seks hænder. Bemærk, at vi sorterer efter kulørrang som
også skal være i gruppen efter klausul. su_name og su_rank har et en til en forhold.
For at se fordelingen af kort i hænder, skal vi gruppere efter kortrangeringskolonnen. Selvfølgelig er der 4 farver af hvert kort, så du vil ikke se et kort i mere end fire hænder.
For at kigge og se, hvem der har esser, kan vi bruge følgende korte forespørgsel. Bemærk, at der er en WHERE-klausul, som udføres, mens rækkerne samles. HAVING udføres efter at rækkerne er samlet.
Oversigt
Disse eksempler er enkle måder at evaluere kendte enheder på. Eksperimenter og brug disse enkle regler.
- Hvis en kolonne er på mållisten og ikke en samlet, skal den være i en GROUP BY-sætning.
- WHERE-sætninger opstår under udvælgelsesprocessen.
- HAVING-sætninger opstår, efter at aggregaterne er afsluttet.
- Kun ikke-aggregater kan være i ORDER BY-klausulen.
- Rækkefølgen af GROUP BY-klausulen har betydning.