JOIN z podzapytaniem

JOIN z podzapytaniem to łączenie tabeli z wynikiem osadzonego zapytania traktowanego jako źródło danych.

Na czym polega JOIN z podzapytaniem

JOIN z podzapytaniem polega na połączeniu tabeli z wynikiem innego zapytania SQL. Podzapytanie umieszczone w klauzuli FROM jest traktowane przez zapytanie zewnętrzne jak tymczasowe źródło danych, podobne do tabeli lub widoku. Musi ono zostać ujęte w nawiasy i otrzymać alias, ponieważ zapytanie nadrzędne potrzebuje nazwy, przez którą odwoła się do jego kolumn. Przykładowa konstrukcja może wyglądać tak: SELECT k.id, k.nazwa, s.suma FROM klienci AS k JOIN (SELECT klient_id, SUM(kwota) AS suma FROM zamowienia GROUP BY klient_id) AS s ON s.klient_id = k.id;

W tym przykładzie podzapytanie najpierw grupuje zamówienia według identyfikatora klienta i oblicza ich łączną wartość. Dopiero wynik tej agregacji jest łączony z tabelą klienci. Dzięki temu główne zapytanie nie operuje bezpośrednio na wszystkich wierszach tabeli zamowienia, lecz na zestawieniu zawierającym jedną wartość dla każdego klienta. Kolejność logiczna wykonania zapytania obejmuje utworzenie źródła wynikowego podzapytania, a następnie wykonanie połączenia określonego przez warunek ON. Szczegółowy plan fizycznego wykonania może jednak zostać zmieniony przez optymalizator konkretnego silnika bazy danych.

Warunek połączenia i zakres zwracanych wierszy

Rodzaj JOIN decyduje o tym, które wiersze pozostaną w wyniku. INNER JOIN zwraca tylko te rekordy, dla których warunek ON jest spełniony po obu stronach. LEFT JOIN zachowuje wszystkie wiersze z tabeli znajdującej się po lewej stronie, nawet jeśli podzapytanie nie zwróci dla nich dopasowania. W brakujących kolumnach pojawia się wtedy wartość NULL. Ma to znaczenie na przykład przy wyświetlaniu wszystkich klientów, także tych, którzy nie mają jeszcze żadnego zamówienia.

Przy użyciu LEFT JOIN trzeba uważać na miejsce filtrowania danych. Warunek umieszczony w klauzuli ON ogranicza dopasowanie podczas łączenia, natomiast warunek w WHERE jest stosowany do gotowego wyniku. Jeżeli po lewej stronie użyto LEFT JOIN, a następnie w WHERE zapisano warunek wymagający niepustej wartości z podzapytania, część zachowania może stać się równoważna INNER JOIN. Przykładowo WHERE s.suma > 0 odrzuci wiersze, dla których s.suma ma wartość NULL. Do zastępowania takiej wartości można użyć funkcji COALESCE, na przykład COALESCE(s.suma, 0), o ile takie znaczenie odpowiada danym.

Kolumny używane w warunku połączenia powinny mieć zgodne znaczenie, a zwykle także zgodne lub możliwe do bezpiecznego porównania typy danych. Łączenie identyfikatora klienta z numerem zamówienia może być formalnie dopuszczone przez niektóre silniki, ale logicznie prowadzi do błędnych dopasowań. Jeżeli podzapytanie zwraca więcej niż jeden wiersz dla tego samego klucza, połączenie może zwielokrotnić rekordy tabeli głównej. Z tego powodu agregowanie w podzapytaniu, zastosowanie odpowiedniego klucza albo świadome zaakceptowanie relacji jeden-do-wielu jest częścią poprawnego projektowania zapytania.

Agregowanie danych przed połączeniem tabel

Jednym z typowych zastosowań tej konstrukcji jest przygotowanie podsumowania przed dołączeniem go do szczegółowych danych. Podzapytanie może zawierać WHERE, funkcje agregujące takie jak COUNT, SUM, AVG, MIN i MAX, a także GROUP BY i HAVING. Przykład SELECT p.id, p.nazwa, x.liczba FROM produkty AS p LEFT JOIN (SELECT produkt_id, COUNT(*) AS liczba FROM pozycje_zamowien GROUP BY produkt_id HAVING COUNT(*) >= 3) AS x ON x.produkt_id = p.id; zwraca produkty oraz liczbę ich użyć w pozycjach zamówień, ale podzapytanie zachowuje tylko grupy zawierające co najmniej trzy pozycje.

Podzapytanie w FROM powinno zwracać kolumny potrzebne do dalszego łączenia i prezentacji. Alias nadany źródłu oraz aliasy kolumn zwiększają czytelność, szczególnie gdy tabela główna i podzapytanie mają pola o podobnych nazwach. Odwołanie x.produkt_id jest jednoznaczne, podczas gdy samo produkt_id może powodować niejasność albo błąd, jeśli taka kolumna występuje w kilku źródłach. Kolumny użyte w GROUP BY określają poziom szczegółowości wyniku. Jeżeli grupowanie obejmuje zarówno klient_id, jak i status, podzapytanie może zwrócić kilka wierszy dla jednego klienta, więc późniejszy JOIN również może zwielokrotnić dane.

Wynik podzapytania nie jest automatycznie trwałym obiektem zapisanym w bazie. Jest częścią pojedynczego polecenia SQL i jego sposób obliczenia zależy od planu wykonania wybranego przez silnik. Przy dużych tabelach znaczenie mają indeksy na kolumnach uczestniczących w filtrach i połączeniach, selektywność warunków oraz liczba wierszy przekazywanych do kolejnych etapów. Nie można jednak zakładać, że utworzenie podzapytania zawsze oznacza fizyczne utworzenie tymczasowej tabeli; optymalizator może przekształcić zapytanie, na przykład przesunąć filtr lub połączyć operacje.

Sprawdzanie zapytania w praktyce serwisowej

Podczas analizy zapytania z JOIN-em i podzapytaniem warto najpierw uruchomić samo podzapytanie i sprawdzić jego strukturę: liczbę kolumn, nazwy aliasów, typy wartości oraz liczbę wierszy dla każdego klucza. Następnie należy wykonać połączenie z ograniczonym zestawem danych i porównać wynik z oczekiwaną relacją. Szczególną uwagę trzeba zwrócić na wartości NULL, duplikaty kluczy, brakujące rekordy oraz sytuację, w której agregacja zwraca inną liczbę wierszy niż zakładano. Do diagnostyki wydajności służą narzędzia planu wykonania dostępne w konkretnym silniku SQL; ich składnia nie jest identyczna we wszystkich produktach.

Jeżeli zapytanie jest używane w aplikacji uruchamianej na laptopie lub komputerze PC, problem może leżeć nie tylko w samej logice SQL, lecz także w konfiguracji programu klienckiego, sterownika albo połączenia z bazą. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym sprawdzaniem środowiska systemowego, w którym działają narzędzia bazodanowe. Sama naprawa sprzętu nie zmienia jednak znaczenia operatorów SQL: poprawność JOIN-u trzeba potwierdzić na podstawie schematu tabel, danych testowych i zamierzonej relacji między rekordami.

Przed wdrożeniem zapytania należy zweryfikować, czy zastosowany rodzaj JOIN-u odpowiada wymaganiom biznesowym zapisanym w modelu danych, czy podzapytanie zwraca jeden wiersz na oczekiwany klucz oraz czy filtrowanie odbywa się na właściwym poziomie. Warto też porównać wynik z niezależnym zapytaniem kontrolnym, na przykład osobnym podsumowaniem wykonanym bez łączenia. Taka kontrola pozwala odróżnić błąd składni od błędu semantycznego, w którym zapytanie wykonuje się poprawnie, ale zwraca niewłaściwe rekordy lub niewłaściwe wartości.