Łączyliśmy już w lewo, prawo i w obydwie strony. Nie łączyliśmy jeszcze w górę i w dół, czyli pionowo. Dziś właśnie o łączeniu pionowym wyników, czyli o UNION, UNION ALL, INTERSECT oraz EXCEPT (MINUS). Inaczej nazywamy je złączeniami na zbiorach.
A dlaczego w ogóle określenie "pionowe"? Bo operujemy na dwóch lub więcej zbiorach uzyskanych z kolejnych, występujących jeden pod drugim, zapytaniach. Czyli łączymy w dół.

UNION i UNION ALL zapewne już znasz z MySQL i być może nawet je stosowałeś. Operator UNION pozwala na połączenie wyników uzyskanych z X (X>1, bo głupio robić UNION na jednym zapytaniu) zapytań. W przypadku UNION będzie to suma wyników bez powtórzeń, a w przypadku UNION ALL duplikaty mogą spać spokojnie.

Przykładowe tabele:

klient1:

klient2:

i zapytanie:

SELECT * FROM klient1 AS k1
UNION /* lub UNION ALL */
SELECT * FROM klient2 AS k2

Wynik z UNION:

Wynik z UNION ALL:

O ile UNION i UNION ALL występują w MySQL natywnie, to co z INTERSECT oraz EXCEPT?

Dziś wpis na FULL! Jak iść, to na całość!
Na Twoim ulubionym blogu pojawiały się już wpisy związane ze złączeniem LEFT JOIN, być może słyszałeś o złączeniu RIGHT JOIN (to jakby odbicie lustrzane LEFT JOIN), ale nie pojawiały się o FULL JOIN.

Skorzystamy z naszego oklepanego przykładu, czyli tabeli klient oraz tabeli zamowienie. W takim przypadku złączenie FULL JOIN wybierze nam klientów bez zamówień, klientów z zamówieniami (lub zamówienia klientów), oraz zamówienia bez klientów. Praktycznym przykładem może być po prostu widok gdzie chcemy zobaczyć listę klientów i ich ewentualne zamówienia oraz zamówienia bez przypisanych klientów. Pewnie zadajesz sobie pytanie skąd zamówienia bez klientów, ale możemy w tym momencie założyć, że ze względu na RODO (to już nie jest typ złączenia...) usunąłeś klientów, ale pozostawiłeś ich zamówienia. Co prawda nie dowiesz się kto dokładnie złożył takiego typu zamówienie, ale będziesz miec zachowaną historię sprzedaży.

Zbudujmy więc zapytanie oparte na tym złączeniu:

SELECT k.id_klient,z.id_zamowienie
FROM klient AS k
FULL OUTER JOIN zamowienie AS z ON z.id_klient=k.id_klient

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FULL OUTER JOIN...

Czyli tyle czytania na marne?

Jak w takim razie wykonać takie złączenie w MySQL?

Zdarzyło Ci się pewnie nie raz pracować na więcej niż jednej tabeli (tabeli bazodanowej, a nie wyników meczu). A jeśli tak, to pewnie zdarzyło Ci się również łączyć obydwie przy pomocy złączenia LEFT JOIN. Jeśli nie, to pozwól, że wspomnę pokrótce na czym polega takie złączenie.

Załóżmy, że masz tabele klientów oraz tabele ich zamówień. Jeśli złączysz obydwie poprzez warunek w klauzuli WHERE lub poprzez INNER JOIN, otrzymasz wynik przedstawiający klientów i ich zamówienia. Ale tylko tych klientów, którzy złożyli (tym razem nie złączyli!) zamówienia. Tych, którzy zarejestrowali się w serwisie, ale nie mają zamówień, nie będzie widać w wyniku tego zapytania. Aby wyświetlić wszystkich klientów i zamówienia, należy użyć wspomnianiego złączenia LEFT JOIN. Dla takich klientów w miejscu ich zamówień otrzymasz wartości null.

Wyobraź sobie, że budujesz teraz system, który posiada możliwość filtracji wyników, a dokładnie pokazania wszystkich klientów i tylko tych z zamówieniami (pewnie jest tam jakiś ptaszek w formularzu, którym włączasz i wyłączasz tą opcję).

I tu rodzi się odwieczne pytanie. Czy da się? Czy da się zbudować tak zapytanie, żeby przekazując określoną wartość wybrać daną pulę wyników i wykorzystać tylko jedno złączenie?

Czasem masz dobry humor, a czasem zły. W obydwu przypadkach możesz zostać w domu.
Czasem do Twojego zapytania dociera wartość wykorzystywana w klauzuli WHERE, a czasem jej kompletnie brak.

Czy w tym przypadku możesz używać stałej składni zapytania bez potrzeby jej modyfikowania w zależności od istnienia tejże wartości?

Jeśli zmierzyłeś się kiedyś z duplikatami rekordów w bazie MySQL, to zapewne doświadczyłeś również zjawiska przeciwnego - ich braku. W tym wpisie zajmiemy się sposobami znalezienia dziur w... nie, nie, nie tam... w autonumeracji.

Jak podążać króliczą norą?

Zaczynasz przygodę z bazami danych. Stworzyłeś pierwszą. Tworzysz tabele. Wypełniasz danymi. Kreujesz pierwsze zapytania wkraczając w fascynujący świat klauzuli WHERE. Już chcesz wykrzyczeć swoją radość całemu światu, możnaby rzecz zJOINować się z nim, ale niestety kolejne zapytania z JOIN podcinają Ci skrzydła.

Błąd SQL (1054): Unknown column 'xxx' in 'on clause'