Dana jest tabela ksiazki z polami: tytul, autor, cena (typu liczbowego). Aby kwerenda SELECT wybrała tylko tytuły, dla których cena jest mniejsza od 50 zł, należy zapisać
Prawidłowa odpowiedź wybiera dokładnie to, o co chodzi w treści zadania: tylko kolumnę tytul z tabeli ksiazki, ale tylko dla tych rekordów, gdzie cena jest mniejsza niż 50. Składnia SELECT tytul FROM ksiazki WHERE cena < 50; jest zgodna ze standardowym SQL i pokazuje dobrą praktykę – pobieramy tylko te dane, które są nam potrzebne, zamiast używać SELECT *. Dzięki temu zapytanie jest lżejsze, szybsze i czytelniejsze, co w większych projektach ma naprawdę duże znaczenie.
Moim zdaniem warto zwrócić uwagę na kilka elementów. Po pierwsze, w klauzuli SELECT podajemy konkretne nazwy kolumn (tu: tytul), nie nazwę tabeli. Po drugie, w FROM podajemy dokładnie nazwę tabeli, z której korzystamy (ksiazki). Po trzecie, warunek WHERE cena < 50 poprawnie porównuje wartość liczbową, bo kolumna cena ma typ liczbowy, więc nie używamy tu cudzysłowów ani żadnych „zł” w środku.
W praktyce podobny wzorzec stosuje się cały czas, np.: SELECT tytul, autor FROM ksiazki WHERE cena <= 30; żeby dostać tańsze książki, albo SELECT tytul FROM ksiazki WHERE cena BETWEEN 20 AND 40; gdy interesuje nas konkretny przedział. W profesjonalnych aplikacjach webowych taka precyzja w definiowaniu zapytań SQL jest podstawą: ułatwia optymalizację, indeksowanie kolumn (np. indeks na kolumnie cena przyspiesza filtrowanie w WHERE) i minimalizuje przesyłanie niepotrzebnych danych między bazą a aplikacją. Dobra praktyka jest też taka, żeby dostosowywać typy danych: skoro cena jest liczbą, to porównujemy ją z liczbą, bez jednostek, a formatowanie typu „50 zł” robimy później w warstwie prezentacji, np. w PHP, JavaScript albo w szablonach widoków.
Moim zdaniem warto zwrócić uwagę na kilka elementów. Po pierwsze, w klauzuli SELECT podajemy konkretne nazwy kolumn (tu: tytul), nie nazwę tabeli. Po drugie, w FROM podajemy dokładnie nazwę tabeli, z której korzystamy (ksiazki). Po trzecie, warunek WHERE cena < 50 poprawnie porównuje wartość liczbową, bo kolumna cena ma typ liczbowy, więc nie używamy tu cudzysłowów ani żadnych „zł” w środku.
W praktyce podobny wzorzec stosuje się cały czas, np.: SELECT tytul, autor FROM ksiazki WHERE cena <= 30; żeby dostać tańsze książki, albo SELECT tytul FROM ksiazki WHERE cena BETWEEN 20 AND 40; gdy interesuje nas konkretny przedział. W profesjonalnych aplikacjach webowych taka precyzja w definiowaniu zapytań SQL jest podstawą: ułatwia optymalizację, indeksowanie kolumn (np. indeks na kolumnie cena przyspiesza filtrowanie w WHERE) i minimalizuje przesyłanie niepotrzebnych danych między bazą a aplikacją. Dobra praktyka jest też taka, żeby dostosowywać typy danych: skoro cena jest liczbą, to porównujemy ją z liczbą, bez jednostek, a formatowanie typu „50 zł” robimy później w warstwie prezentacji, np. w PHP, JavaScript albo w szablonach widoków.
W zapytaniach SQL bardzo łatwo popełnić drobny błąd składniowy albo logiczny, który na pierwszy rzut oka wygląda niewinnie, a w praktyce całkowicie zmienia działanie kwerendy. W tym pytaniu widać kilka typowych potknięć, które często pojawiają się u osób zaczynających pracę z bazami danych.
Jednym z błędów jest używanie SELECT * wtedy, gdy wcale nie potrzebujemy wszystkich kolumn. Z mojego doświadczenia wynika, że to nawyk z pierwszych ćwiczeń: * działa, więc wszyscy go używają. Problem jest taki, że SELECT * FROM ksiazki WHERE cena < 50; co prawda poprawnie filtruje po cenie, ale zwraca wszystkie kolumny, a pytanie wyraźnie mówi o „tytułach”. W realnych systemach oznacza to większy transfer danych, gorszą czytelność kodu i trudniejsze utrzymanie, szczególnie gdy tabela ma kilkanaście czy kilkadziesiąt kolumn.
Druga kwestia to porównywanie liczby do tekstu. Jeśli kolumna cena ma typ liczbowy, to warunki w WHERE powinny używać wartości liczbowych, np. 50, bez cudzysłowów i bez jednostek waluty. Konstrukcje w stylu cena > '50 zł' są błędne semantycznie: baza próbuje wtedy porównywać liczbę z napisem, co w zależności od silnika SQL skończy się błędem, nieprzewidywalną konwersją albo po prostu pustym wynikiem. Jednostka waluty, czyli „zł”, powinna być dodawana dopiero na etapie prezentacji danych, a nie przechowywana w kolumnie liczbowej.
Pojawia się też nieporozumienie co do tego, co podajemy po SELECT, a co po FROM. Po SELECT wymieniamy kolumny (np. tytul, autor), natomiast po FROM – nazwy tabel (np. ksiazki). Odwrócenie tego, typu SELECT ksiazki FROM tytul, jest po prostu niepoprawną składnią i nie ma sensu z punktu widzenia modelu relacyjnego. To jest jeden z częstszych błędów: mylenie poziomu struktury bazy (tabele) z poziomem danych (kolumny).
Dobrym nawykiem jest więc: po pierwsze, zawsze zastanowić się, które kolumny naprawdę są potrzebne; po drugie, pilnować typów danych – liczby porównujemy z liczbami, tekst z tekstem; po trzecie, dbać o poprawną kolejność i znaczenie słów kluczowych SQL. Takie drobne szczegóły przekładają się potem na wydajność, bezpieczeństwo i jakość całej aplikacji webowej.
Jednym z błędów jest używanie SELECT * wtedy, gdy wcale nie potrzebujemy wszystkich kolumn. Z mojego doświadczenia wynika, że to nawyk z pierwszych ćwiczeń: * działa, więc wszyscy go używają. Problem jest taki, że SELECT * FROM ksiazki WHERE cena < 50; co prawda poprawnie filtruje po cenie, ale zwraca wszystkie kolumny, a pytanie wyraźnie mówi o „tytułach”. W realnych systemach oznacza to większy transfer danych, gorszą czytelność kodu i trudniejsze utrzymanie, szczególnie gdy tabela ma kilkanaście czy kilkadziesiąt kolumn.
Druga kwestia to porównywanie liczby do tekstu. Jeśli kolumna cena ma typ liczbowy, to warunki w WHERE powinny używać wartości liczbowych, np. 50, bez cudzysłowów i bez jednostek waluty. Konstrukcje w stylu cena > '50 zł' są błędne semantycznie: baza próbuje wtedy porównywać liczbę z napisem, co w zależności od silnika SQL skończy się błędem, nieprzewidywalną konwersją albo po prostu pustym wynikiem. Jednostka waluty, czyli „zł”, powinna być dodawana dopiero na etapie prezentacji danych, a nie przechowywana w kolumnie liczbowej.
Pojawia się też nieporozumienie co do tego, co podajemy po SELECT, a co po FROM. Po SELECT wymieniamy kolumny (np. tytul, autor), natomiast po FROM – nazwy tabel (np. ksiazki). Odwrócenie tego, typu SELECT ksiazki FROM tytul, jest po prostu niepoprawną składnią i nie ma sensu z punktu widzenia modelu relacyjnego. To jest jeden z częstszych błędów: mylenie poziomu struktury bazy (tabele) z poziomem danych (kolumny).
Dobrym nawykiem jest więc: po pierwsze, zawsze zastanowić się, które kolumny naprawdę są potrzebne; po drugie, pilnować typów danych – liczby porównujemy z liczbami, tekst z tekstem; po trzecie, dbać o poprawną kolejność i znaczenie słów kluczowych SQL. Takie drobne szczegóły przekładają się potem na wydajność, bezpieczeństwo i jakość całej aplikacji webowej.