Poprawne zapytanie korzysta z jawnego złączenia tabel: SELECT nazwisko, Miasto FROM Osoby JOIN Adresy ON Osoby.Adresy_id = Adresy.id;. Kluczowe są tu dwie rzeczy: użycie słowa kluczowego JOIN oraz właściwy warunek ON, który łączy klucz obcy z kluczem głównym. W tabeli Osoby kolumna Adresy_id jest kluczem obcym (FK), który wskazuje na kolumnę id w tabeli Adresy. To dokładnie odzwierciedla relację jeden‑do‑wielu narysowaną na diagramie. Dzięki temu baza danych wie, które miasto przypisać do którego nazwiska. Takie podejście jest zgodne ze standardem SQL i dobrą praktyką w relacyjnych bazach danych. Jawne JOIN-y są czytelne, łatwe do modyfikacji (np. dodanie kolejnych tabel lub warunków filtrowania) i dobrze współpracują z optymalizatorem zapytań. W praktycznych projektach, np. w aplikacjach webowych, właśnie tak buduje się zapytania: łączymy tabelę użytkowników lub klientów z tabelą adresów, zamówień, faktur, logów itp. zawsze po kluczach głównych i obcych, a nie po przypadkowo dobranych kolumnach. Moim zdaniem warto od razu wyrabiać sobie nawyk pisania nazw tabel przy kolumnach, czyli Osoby.nazwisko, Adresy.Miasto – zmniejsza to ryzyko konfliktu nazw i poprawia czytelność kodu SQL. Gdyby w przyszłości w którejś tabeli pojawiła się druga kolumna o nazwie Miasto, zapytanie nadal byłoby jednoznaczne. W większych systemach, gdzie dochodzą dodatkowe warunki (WHERE, ORDER BY, GROUP BY), taka struktura zapytania z JOIN ON jest po prostu dużo łatwiejsza w utrzymaniu i debugowaniu. Warto też pamiętać, że relacja jeden‑do‑wielu oznacza, że jedna osoba może mieć wiele adresów albo jeden adres może być przypisany do wielu osób – dokładne powiązanie zależy od modelu, ale technika złączenia po kluczu obcym pozostaje taka sama.
W tym zadaniu widać kilka typowych pułapek związanych z łączeniem tabel w SQL. Często spotyka się podejście, że wystarczy wypisać kilka tabel po przecinku w klauzuli FROM i baza danych sama się domyśli, jak je połączyć. Niestety tak to nie działa. Jeśli podamy FROM Osoby, Adresy bez żadnego warunku, otrzymamy tzw. iloczyn kartezjański. Oznacza to, że każda osoba zostanie połączona z każdym adresem, co w praktyce daje ogromny, kompletnie bezsensowny zestaw danych. To jest bardzo częsty błąd początkujących: zapytanie technicznie się wykonuje, ale wynik nie ma żadnego logicznego związku z modelem danych. Drugi problem to łączenie tabel po niewłaściwych kolumnach. Zdarza się założenie, że skoro obie tabele mają kolumnę id, to można je po prostu zrównać w warunku WHERE Osoby.id = Adresy.id. Jest to myślenie intuicyjne, ale błędne z punktu widzenia projektowania relacyjnego. Kolumna id w każdej tabeli jest zwykle osobnym kluczem głównym i nie ma powodu, żeby ich wartości się pokrywały. W poprawnym modelu relacji używa się klucza obcego, tutaj Osoby.Adresy_id, który jawnie wskazuje na Adresy.id. To właśnie te dwie kolumny należy ze sobą powiązać. Kolejna pułapka to mylenie składni JOIN z warunkiem łączenia. Fragment Osoby.Adresy_id = Adresy.id nie może znajdować się w miejscu, gdzie SQL oczekuje listy tabel po FROM albo słowa kluczowego JOIN. To jest wyrażenie logiczne, które powinno znaleźć się w klauzuli ON (w przypadku JOIN) lub w WHERE (w starszym stylu zapisu). Moim zdaniem ważne jest, żeby w głowie rozdzielić trzy elementy: najpierw wymieniamy tabele, które chcemy połączyć, potem określamy typ złączenia (JOIN, LEFT JOIN itd.), a dopiero na końcu definiujemy warunek powiązania ON klucz_obcy = klucz_główny. Jeśli pomieszamy te poziomy, wychodzą dziwne konstrukcje, które są po prostu niezgodne ze składnią SQL. Dobra praktyka branżowa jest taka, że używamy jawnych JOIN-ów z precyzyjnym warunkiem ON i zawsze sprawdzamy, czy łączymy po właściwych kolumnach wynikających z relacji w modelu danych.