Baza danych zawiera tabelę faktury o polach: numer, data, id_klienta, wartosc, status. Każdego dnia generowany jest raport faktur z bieżącego dnia. Wyświetlane są jedynie numery i wartości faktur. Która z kwerend SQL służy do stworzenia tego raportu?
A.
SELECT numer, wartosc FROM faktury WHERE data = CURRENT_DATE();
B.
SELECT * FROM faktury;
C.
SELECT * FROM faktury WHERE data = CURRENT_DATE();
D.
SELECT numer, wartosc FROM faktury;
Pytanie z egzaminu CKE, czerwiec 2018 (arkusz E.14-X-18.06).
Ta kwerenda spełnia dokładnie oba warunki opisane w treści zadania: wybiera tylko potrzebne kolumny oraz ogranicza wynik do faktur z bieżącego dnia. Fragment SELECT numer, wartosc oznacza projekcję danych, czyli wskazanie, które pola mają zostać pokazane w raporcie. Nie pobieramy więc id_klienta, statusu ani całych rekordów, bo raport ma zawierać wyłącznie numery i wartości faktur. FROM faktury wskazuje tabelę źródłową, a WHERE data = CURRENT_DATE() filtruje rekordy tak, aby zostały tylko te, których data jest równa dzisiejszej dacie. Moim zdaniem to bardzo praktyczny przykład dobrej kwerendy raportowej: jest konkretna, czytelna i nie pobiera nadmiarowych danych. W pracy z bazą to ważne, bo SELECT * w raportach często niepotrzebnie obciąża serwer i sieć. Warto też pamiętać, że przy większej tabeli dobrze jest mieć indeks na kolumnie data, ponieważ taki raport będzie wykonywany codziennie. Jeśli pole data byłoby typu DATETIME z godziną, wtedy w praktyce czasem lepszy jest filtr zakresowy od początku do końca dnia, ale dla pola przechowującego samą datę zapis z CURRENT_DATE() jest jak najbardziej sensowny.
W tym zadaniu łatwo pomylić dwie różne rzeczy: wybór kolumn oraz wybór rekordów. Samo SELECT numer, wartosc FROM faktury; rzeczywiście pokazuje tylko numer i wartość, czyli zgadza się z częścią dotyczącą wyglądu raportu. Problem jest taki, że bez klauzuli WHERE baza zwróci faktury ze wszystkich dni, a raport ma być generowany tylko dla bieżącego dnia. To częsty błąd: ktoś patrzy tylko na listę kolumn i zapomina, że w raportach prawie zawsze potrzebny jest warunek ograniczający dane. Z kolei użycie SELECT * powoduje pobranie wszystkich pól z tabeli, czyli numeru, daty, id_klienta, wartości i statusu. Nawet jeśli pojawi się poprawny filtr po dacie, wynik nadal nie spełnia wymagania, bo raport ma wyświetlać jedynie numery i wartości faktur. W praktyce SELECT * bywa wygodne podczas szybkiego sprawdzania danych, ale w gotowych raportach i aplikacjach nie jest dobrą praktyką. Pobiera za dużo informacji, utrudnia kontrolę nad strukturą wyniku i może ujawniać dane, które nie powinny być widoczne. Jeszcze gorzej, gdy brakuje zarówno wskazania konkretnych kolumn, jak i filtra daty, bo wtedy dostajemy pełną tabelę faktur, a nie raport dzienny. Poprawne rozumowanie powinno iść tak: najpierw określam, jakie kolumny mają być widoczne, potem dokładam warunek, które wiersze mają trafić do wyniku. Tutaj warunek opiera się na kolumnie data i funkcji CURRENT_DATE(), czyli dacie aktualnej według serwera bazy danych.