JOIN z warunkiem USING nie jest obsługiwany w SQL Server — zamiast niego stosuje się jawną klauzulę ON.
Dlaczego SQL Server nie rozpoznaje USING w JOIN
Klauzula USING jest składnią spotykaną w niektórych innych systemach baz danych, ale Microsoft SQL Server jej nie obsługuje. Dotyczy to instrukcji SELECT z operacjami łączenia tabel. Próba napisania zapytania w rodzaju JOIN druga_tabela USING (id) kończy się błędem składni, ponieważ parser T-SQL oczekuje po słowie JOIN jawnie zapisanej klauzuli ON albo konstrukcji CROSS JOIN, która nie określa warunku dopasowania.
W SQL Server warunek połączenia należy zapisać przez wskazanie kolumn z obu tabel, na przykład JOIN Zamowienia AS z ON z.KlientID = k.KlientID. Lewa i prawa strona porównania są wtedy jednoznaczne, nawet gdy kolumny mają taką samą nazwę. SQL Server nie skraca automatycznie tego zapisu na podstawie wspólnej nazwy kolumny i nie usuwa powtórzonej kolumny z zestawu wynikowego tak, jak może to robić silnik obsługujący USING.
Jawna klauzula ON w zapytaniach T-SQL
Przykładowe połączenie tabel Klienci i Zamowienia w SQL Server może wyglądać następująco: SELECT k.KlientID, k.Nazwa, z.ZamowienieID FROM Klienci AS k INNER JOIN Zamowienia AS z ON z.KlientID = k.KlientID;. Alias k oznacza tabelę klientów, a alias z tabelę zamówień. Operator = określa, że rekordy mają zostać dopasowane wtedy, gdy wartości identyfikatora klienta są równe.
Jeżeli kolumny mają różne nazwy, nie stanowi to problemu, ponieważ ON pozwala wskazać dowolną logicznie powiązaną parę. Przykładowo można użyć warunku ON z.CustomerNumber = k.Number, jeżeli taki model danych został przyjęty w konkretnej bazie. Warunek może obejmować także kilka kolumn: ON z.MagazynID = m.MagazynID AND z.Kod = m.Kod. W takim przypadku oba porównania muszą być prawdziwe, aby SQL Server połączył wiersze.
Warto odróżnić warunek łączenia od filtra wyników. Predykat zapisany w ON określa, które wiersze tabel są ze sobą powiązane. Predykat w WHERE odrzuca wiersze już po uwzględnieniu rodzaju złączenia. Różnica ma szczególne znaczenie dla LEFT JOIN. Zapis LEFT JOIN Zamowienia AS z ON z.KlientID = k.KlientID AND z.Status = 'Otwarty' zachowuje klientów bez otwartych zamówień i zwraca dla nich wartości NULL po stronie tabeli zamówień. Przeniesienie warunku statusu do WHERE może usunąć takich klientów z wyniku, zmieniając praktyczne działanie zapytania na podobne do INNER JOIN.
Kolumny wynikowe i typowe błędy przy zamianie USING
Przy przepisywaniu zapytania z USING na składnię SQL Server trzeba jawnie ustalić listę kolumn w SELECT. SQL Server nie zapewnia automatycznego połączenia dwóch kolumn o tej samej nazwie w jedną kolumnę wyniku. Zapis SELECT * może więc zwrócić zarówno k.KlientID, jak i z.KlientID. Obie wartości mogą być równe dla poprawnie dopasowanych wierszy, ale nadal są odrębnymi kolumnami pochodzącymi z różnych tabel.
Bez aliasów kwalifikujących nazwy może pojawić się błąd niejednoznacznej nazwy kolumny, na przykład gdy obie tabele zawierają kolumnę Data, Status albo ID. Bezpieczny zapis to SELECT k.Nazwa, z.Status FROM Klienci AS k INNER JOIN Zamowienia AS z ON z.KlientID = k.KlientID. Alias nie zmienia danych ani struktury tabeli; wskazuje jedynie, z którego źródła ma zostać pobrana kolumna.
Podczas zamiany USING nie należy zastępować warunku połączenia przecinkiem między tabelami ani dopisywać przypadkowego WHERE. Niewłaściwe połączenie może utworzyć iloczyn kartezjański, czyli zestawić każdy wiersz jednej tabeli z każdym wierszem drugiej. W SQL Server jawny JOIN ... ON ułatwia zauważenie brakującego lub niepełnego warunku. Trzeba też sprawdzić, czy porównywane kolumny mają zgodne typy danych oraz czy warunek obejmuje cały klucz, gdy relacja opiera się na kluczu złożonym.
Znaczenie poprawnego zapisu dla analizy bazy SQL Server
Brak obsługi USING jest cechą składni Microsoft SQL Server, a nie sygnałem uszkodzenia tabel, indeksów czy połączenia z serwerem. Jeżeli narzędzie zgłasza błąd przy słowie USING, pierwszym krokiem jest przepisanie instrukcji do dialektu T-SQL i jawne wskazanie relacji w ON. Dopiero gdy poprawna składnia nadal zwraca błąd, należy analizować nazwy tabel, kolumn, uprawnienia, schemat oraz typy danych.
W diagnostyce zapytania warto sprawdzić, czy warunek ON łączy kolumnę klucza głównego z odpowiednią kolumną klucza obcego, zamiast przypadkowo porównywać pola o podobnych nazwach. Można również uruchomić samo zapytanie z ograniczoną listą kolumn i dodać warunki stopniowo. Wynik należy oceniać pod kątem liczby wierszy, powtórzeń oraz obecności wartości NULL. Poprawna składnia nie gwarantuje poprawnej logiki biznesowej: połączenie po kolumnie nieunikalnej może zwielokrotnić rekordy, nawet jeśli SQL Server wykona instrukcję bez błędu.
W przypadku zapytań używanych w programie serwisowym, raporcie albo narzędziu administracyjnym trzeba zachować zgodność całej instrukcji z T-SQL. Dotyczy to nie tylko JOIN, lecz także sposobu oznaczania aliasów, funkcji, konwersji typów i filtrów. Zamiana USING (Kolumna) na ON a.Kolumna = b.Kolumna jest właściwym kierunkiem, ale przed wdrożeniem należy jeszcze potwierdzić, że zwracane kolumny mają oczekiwane nazwy i nie zawierają niezamierzonego duplikatu.
