W podanym przykładzie wykonano dwa niezależne zapytania do tej samej tabeli mieszkańcy:
- pierwsze wybiera osoby, dla których miasto='Poznań',
- drugie wybiera osoby, dla których miasto='Kraków'.
Następnie wyniki są połączone operatorem UNION ALL. Kluczowe jest słowo ALL: oznacza, że SQL nie usuwa duplikatów między częściami składowymi. Innymi słowy, wynik końcowy to "doklejenie" jednego zbioru wierszy pod drugi.
Jeżeli oba SELECT-y:
- pobierają te same kolumny (nazwisko, imie),
- pochodzą z tej samej tabeli,
- różnią się wyłącznie warunkiem w klauzuli WHERE,
to można je zapisać jako jedno zapytanie, łącząc warunki operatorem logicznym OR:
SELECT nazwisko, imie
FROM mieszkańcy
WHERE miasto='Poznań' OR miasto='Kraków';
To zapytanie zwraca wszystkie wiersze spełniające którykolwiek z warunków, czyli dokładnie te same rekordy, które w wersji z UNION ALL trafiają do wyniku z pierwszej lub z drugiej części.
Dlaczego pozostałe propozycje są błędne:
- HAVING służy do filtrowania wyników po agregacji (zwykle z GROUP BY), a nie do porównania pojedynczej kolumny z literałami w podanej formie; dodatkowo składnia "miasto HAVING 'Poznań'" jest niepoprawna.
- Użycie AS do aliasowania tabeli nie zastępuje warunku filtrowania; zapis z "'Poznań' OR 'Kraków'" nie tworzy sensownego kryterium wierszy.
- BETWEEN wymaga zakresu (dolna i górna granica) i ma inną składnię; nie zapisuje się go jako "BETWEEN 'Poznań' OR 'Kraków'". Nawet poprawne BETWEEN dla tekstu oznaczałoby porządek leksykograficzny, a nie "jedno z dwóch miast".
Wskazówka egzaminacyjna: gdy widzisz dwa SELECT-y z tej samej tabeli różniące się tylko prostym warunkiem, często da się je scalić przez OR (albo przez IN (...)), zachowując znaczenie wyniku.
