Które zapytanie SQL posłuży do wyszukania z przedstawionej tabeli Pacjenci wyłącznie imion i nazwisk pacjentów, których ostatnia wizyta odbyła się przed 1 stycznia 2024 roku?
| Pole | Typ |
|---|---|
| id (klucz główny) | INTEGER |
| imie | TEXT |
| nazwisko | TEXT |
| adres | TEXT |
| rok_urodzenia | YEAR |
| informacje | TEXT |
| data_ostatniej_wizyty | DATE |
A.
SELECT imie, nazwisko FROM Pacjenci WHERE data_ostatniej_wizyty < '2024-01-01'
B.
SELECT imie, nazwisko FROM Pacjenci WHERE rok_urodzenia < '2024-01-01'
C.
SELECT * FROM Pacjenci WHERE data_ostatniej_wizyty LIKE '2024-01-01'
D.
SELECT * FROM Pacjenci WHERE data_ostatniej_wizyty <= '2024-01-01'
Zapytanie SELECT imie, nazwisko FROM Pacjenci WHERE data_ostatniej_wizyty < '2024-01-01' spełnia oba warunki z treści zadania. Po pierwsze, w klauzuli SELECT wskazane są tylko dwie kolumny: imie oraz nazwisko, więc wynik nie będzie zawierał adresu, identyfikatora, informacji medycznych ani innych pól. To jest ważne także praktycznie, bo w bazach z danymi pacjentów nie powinno się pobierać więcej danych niż potrzeba. Po drugie, warunek WHERE filtruje rekordy po kolumnie data_ostatniej_wizyty, czyli dokładnie po tej informacji, o którą pyta zadanie. Operator < oznacza „wcześniej niż”, więc data 2024-01-01 nie zostanie już uwzględniona. Format '2024-01-01' jest typowym, bezpiecznym formatem ISO dla dat w SQL i dobrze nadaje się do porównań w kolumnach typu DATE. Z mojego doświadczenia to jedna z tych dobrych praktyk, które naprawdę warto sobie utrwalić: wybieramy konkretne kolumny zamiast SELECT *, filtrujemy po właściwym polu i używamy precyzyjnego operatora porównania.
W tym pytaniu łatwo pomylić dwa różne wymagania: jakie kolumny mają zostać pokazane oraz które rekordy mają zostać wybrane. Użycie SELECT * oznacza pobranie wszystkich pól z tabeli, czyli na przykład id, adresu, roku urodzenia, informacji dodatkowych i daty wizyty. To nie pasuje do polecenia, bo użytkownik ma dostać wyłącznie imiona i nazwiska. W praktyce SELECT * bywa wygodne podczas szybkiego testowania, ale w aplikacji produkcyjnej jest raczej słabym nawykiem: przesyła niepotrzebne dane, utrudnia kontrolę nad wynikiem i może ujawnić informacje, których nie powinno się pokazywać. Równie istotny jest operator porównania. Warunek data_ostatniej_wizyty <= '2024-01-01' obejmuje także wizyty dokładnie z 1 stycznia 2024 roku, a w zadaniu jest mowa o wizytach przed tą datą. Tu musi być znak <, bez równości. Zastosowanie LIKE do daty też nie jest dobrym pomysłem, bo LIKE służy głównie do porównywania wzorców tekstowych, na przykład nazwisk zaczynających się od określonych liter. Nawet jeśli niektóre silniki SQL pozwolą technicznie użyć LIKE na wartości daty po konwersji, to nie opisuje ono zakresu „przed datą”, tylko dopasowanie tekstu. Błędne jest też filtrowanie po rok_urodzenia, ponieważ ta kolumna mówi o dacie lub roku urodzenia pacjenta, a nie o terminie ostatniej wizyty. Dodatkowo porównywanie roku urodzenia z pełną datą '2024-01-01' miesza znaczenia danych. Moim zdaniem najważniejsza zasada jest prosta: najpierw sprawdź, z której kolumny pochodzi warunek, potem wybierz właściwy operator, a dopiero na końcu zdecyduj, które kolumny mają trafić do wyniku.