Tabele: Studenci, Zapisy, Zajecia są powiązane relacją. Aby wybrać jedynie nazwiska studentów oraz odpowiadające im idZajecia dla studentów z grupy 15, należy wydać kwerendę
W tej odpowiedzi zostało wszystko zrobione zgodnie z zasadami projektowania relacyjnych baz danych oraz praktyk SQL. Użycie JOIN zamiast starego stylu łączenia tabel przez przecinek i warunek WHERE to nie tylko kwestia czytelności, ale już od dawna standard branżowy. JOIN jasno pokazuje, na jakiej zasadzie łączą się tabele, w tym wypadku Studenci i Zapisy – łączymy po id studenta, bo tylko w taki sposób faktycznie powiążemy konkretne osoby z ich zapisami na zajęcia. WHERE grupa = 15 dodatkowo ogranicza wynik do tej konkretnej grupy studentów, co jest bardzo powszechną praktyką filtrowania wyników w zapytaniach. Przy bardziej złożonych systemach, gdzie mamy dużo relacji, taki zapis jest czytelny i łatwy do modyfikacji. Z mojego doświadczenia, jeżeli ktoś pracuje z większą ilością danych, czy nawet pisze bardziej skomplikowane raporty, to dokładnie taki zapis – z wyraźnie określonym JOIN-em i selekcją kolumn – bardzo ułatwia życie. Warto też pamiętać, że w praktyce biznesowej często chcemy wyciągnąć konkretną informację o użytkownikach lub powiązanych encjach, a nie wszystko naraz. W tym zadaniu to właśnie połączenie po idStudenta i selekcja po grupie daje najprecyzyjniejszy i najczystszy rezultat, zgodny i z logiką, i praktyką codziennej pracy z bazami danych.
Pierwszym istotnym problemem w niepoprawnych zapytaniach jest brak prawidłowego połączenia tabel na właściwych kluczach. W relacyjnych bazach danych, aby sensownie połączyć dane z różnych tabel, należy wykorzystać klucze główne i obce, które jasno definiują powiązania między obiektami. Jeśli zapomni się o warunku JOIN albo połączy się tabele po błędnych kolumnach (na przykład próbując połączyć idStudenta z idZajecia lub pomijając warunek ON), baza zwróci błędne wyniki lub wręcz nie pozwoli wykonać zapytania. To typowy błąd początkujących, którzy nie zawsze rozumieją, jak bardzo ważne jest precyzyjne określenie relacji – w rzeczywistych bazach danych relacji jest wiele, a niewłaściwe powiązanie może prowadzić do powstawania kartuzjańskiego iloczynu, czyli powielania danych bez rzeczywistego sensu. Brak filtru WHERE grupa = 15 skutkuje wyciągnięciem danych dla wszystkich studentów, co może być ogromnym problemem przy dużych bazach i całkowicie rozmija się z celem kwerendy. Moim zdaniem, wiele osób zapomina, że filtrowanie to podstawa – bez tego, szczególnie przy produkcyjnych bazach, można zarówno błędnie interpretować wyniki, jak i mocno przeciążyć system niepotrzebnym ruchem. Takie błędy wynikają często z braku systematycznego podejścia do projektowania zapytań i nieuważnego czytania struktury tabel. Warto od razu przyzwyczajać się do pracy zgodnie z konwencjami, bo to przekłada się na bezpieczeństwo, wydajność i poprawność działania całego systemu. W praktyce – nawet drobny błąd w składni JOIN lub brak filtrowania na kluczowej kolumnie może wywołać lawinę problemów, zwłaszcza gdy kwerenda staje się częścią większej aplikacji biznesowej lub raportu dla zarządu.