Niektórzy ludzie dokładają wszelkich starań, aby uniknąć klauzul GROUP BY i HAVING w swoich zapytaniach. Komunikaty o błędach są wybredne, ale zwykle mają rację. Słowa kluczowe GROUP BY i HAVING są niezbędne do dobrego raportowania SQL.
Podstawowym powodem GROUP BY jest zmniejszenie liczby wierszy, zwykle przez agregację. Daje tylko jeden wiersz dla każdej pasującej grupy z danych wejściowych. Pozwala to na wykonywanie skomplikowanych obliczeń za pomocą zwykłego SQL.
Przykład owoców:
Mamy trochę owoców:
Ten kolejny przypadek pozwala nam patrzeć w przyszłość. Jakie owoce będą dostępne w połowie roku? Robimy to z tym samym zapytaniem, co powyżej, jednak po uruchomieniu zapytania sprawdzamy wartości min(fresh_until) za pomocą klauzuli having. POSIADAJĄC to sposób, w jaki kwalifikujesz agregat.
Wszystkie jabłka i winogrona będą dostępne w połowie roku.
Lista elementów pomiędzy SELECT i FROM, lista docelowa. może zawierać nieagregaty i agregaty. Te nieagregowane kolumny na liście docelowej
powinny znajdować się w klauzuli group by. Komunikat o błędzie tak mówi. Kolejność kolumn w grupie według klauzul ma znaczenie. Określa sposób grupowania agregatów. Kolejność jest często hierarchiczna. To, co to oznacza dla twoich kolumn, to twoje skupienie. Mogą to być owoce, źródła i/lub świeże_do daty.
Przykłady kart do gry
Przyjrzyjmy się kolejnemu zestawowi przykładów, które ilustrują wydobywanie informacji z kart do gry. Możesz dowiedzieć się więcej o kartach na kartach standardowych Wikipedii.
Załóżmy, że programowo rozdajesz sześć 5-kartowych rąk, tak jak sześć osób grających w pokera. W tym rozdaniu używa się łącznie 30 kart. Są w ręce tabelę podobną do poniższej, w której nazwy kart i kolorów są połączone tabelami przeglądowymi. Przechowujemy rangi, abyśmy mogli prawidłowo sortować. Używamy nazw do wyświetlania. Imiona i rangi mają związek jeden do jednego dla każdej z kart i kolorów.
Jaka jest liczba kolorów dla każdego rozdania? Tak naprawdę zależy nam tylko na rękach, które mają 3 lub więcej kart tego samego koloru. To powie nam, kto ma większe szanse na pokera. Zauważ, że chociaż GROUP BY wydaje się sugerować ORDER BY, tak nie jest. ORDER BY musi być wyraźne.
Co z tego, jeśli źle pogrupowałeś zapytanie? Jeśli ta ręka tabela nie jest pogrupowana według handidów, otrzymasz 30 rekordów 6 rozdań po 5 kart. Gdybyś miał agregaty, byłyby pogrupowane według wierszy. Niezbyt pomocne.
Jeśli zagregujesz nazwę karty i nie uwzględnisz
nazwy karty solo na liście docelowej i spróbujesz uporządkować według nazwy karty,
otrzymasz komunikat o błędzie, że nie powinna być w
kolejność po klauzuli. Klauzula order by powinna zawierać
elementy klauzuli group by.
Jeśli jednak nazwa karty jest jawnie na liście docelowej,
wtedy nazwa karty musi znajdować się w klauzuli group by i
dlatego jest dozwolona w klauzuli order by.
Jeśli zapytanie jest według koloru, będzie co najmniej 1 lub maksymalnie 4 rekordy na kolor dla każdego z sześciu rozdań. Zauważ, że sortujemy według rankingu kolorów, które
również muszą znajdować się w klauzuli group by. su_name i su_rank są w relacji jeden do jednego.
Aby zobaczyć rozkład kart na ręce, musimy pogrupować według kolumny z rankingiem kart. Oczywiście są 4 kolory każdej karty, więc nie zobaczysz karty w więcej niż czterech rozdaniach.
Aby zerknąć i zobaczyć, kto ma asy, możemy użyć następującego krótkiego zapytania. Zauważ, że istnieje klauzula WHERE, która jest wykonywana podczas zbierania wierszy. HAVING jest wykonywane po zebraniu wierszy.
Podsumowanie
Te przykłady to proste sposoby oceny znanych jednostek. Eksperymentuj i korzystaj z tych prostych zasad.
- Jeśli kolumna znajduje się na liście docelowej, a nie jako agregat, musi być w klauzuli GROUP BY.
- Klauzule GDZIE występują podczas procesu selekcji.
- Klauzule HAVING występują po zakończeniu agregacji.
- Tylko nieagregaty mogą znajdować się w klauzuli ORDER BY.
- Porządek klauzuli GROUP BY ma znaczenie.
