Ta odpowiedź jest dokładnie tym, czego oczekuje się w praktycznej pracy z relacyjnymi bazami danych. Kluczowe jest tutaj poprawne połączenie tabeli Studenci z tabelą Zapisy na podstawie klucza głównego Studenci.id oraz obcego Zapisy.idStudenta. To klasyczna sytuacja, gdzie chcemy wydobyć informacje z dwóch tabel powiązanych relacją jeden-do-wielu. Dzięki użyciu JOIN oraz warunku ON określającego relację, uzyskujemy możliwość pobrania nazwisk studentów i odpowiadających im identyfikatorów zajęć. Warunek WHERE ogranicza wynik do studentów z konkretnej grupy, co jest bardzo częstym wymaganiem biznesowym np. przy generowaniu list obecności czy analizie frekwencji. Takie podejście jest czytelne, zgodne ze składnią SQL ANSI i pozwala uniknąć nieporozumień przy większych kwerendach. Moim zdaniem warto pamiętać, że stosowanie jawnych JOIN-ów zamiast łączenia 'po przecinku' czy w warunku WHERE, ułatwia późniejszą rozbudowę zapytań oraz ogranicza ryzyko tzw. 'kartesjańskiego koszmaru', czyli niekontrolowanego zwielokrotnienia rekordów. Warto też wiedzieć, że zapis ten jest optymalny wydajnościowo, bo wykorzystuje istniejące klucze i indeksy – a to podstawa dobrych praktyk w pracy z bazami danych. Generalnie, jak się opanuje ten schemat, to potem większość operacji na relacyjnych bazach danych jest dużo łatwiejsza.
Wśród proponowanych rozwiązań pojawiają się charakterystyczne błędy, często spotykane przy pierwszych próbach pracy z relacyjnymi bazami danych. Bardzo łatwo jest pomylić się na etapie łączenia tabel, zwłaszcza gdy nie do końca rozumie się, jak działa klucz główny i obcy w praktyce. Jeden z typowych problemów polega na pominięciu warunku określającego, w jaki sposób tabele mają być połączone – wtedy system bazodanowy tworzy tzw. iloczyn kartezjański, czyli paruje każdy rekord z jednej tabeli z każdym z drugiej, co zwykle daje absurdalnie dużo wyników i nie ma nic wspólnego z rzeczywistością. Popularny błąd to też użycie niewłaściwych pól do łączenia – np. próba połączenia idStudenta z idZajecia, które są ze sobą kompletnie niepowiązane, bo reprezentują dwa różne byty. Z mojego doświadczenia wynika, że często myli się pole id w tabeli Studenci z polem idZajecia w tabeli Zapisy – to są zupełnie inne klucze i nie mają prawa się zgadzać. Inna pułapka pojawia się, gdy zapomni się o warunku WHERE filtrującym po konkretnej grupie, przez co wynik zawiera dane wszystkich studentów, a nie tylko tych z interesującej nas grupy. Trzeba też pamiętać, że poprawna kolejność oraz jawne stosowanie JOIN z warunkiem ON to nie tylko kwestia składni, ale i wydajności oraz czytelności kodu. Warto mocno utrwalić sobie, że łączenie przez JOIN i jasno określony warunek ON to podstawa dobrej praktyki i niemal zawsze sprawdza się przy pracy z większymi, złożonymi bazami danych – zupełnie inaczej niż domyślne, niejawne łączenia czy łączenie po złych polach.