W tabeli produkt znajdują się przedmioty wyprodukowane po 2000 roku, z polami nazwa i rok_produkcji. Klauzula SQL
SELECT * FROM `produkt` WHERE SUBSTR(rok_produkcji, 3, 2) > 17;wyświetli listę przedmiotów wyprodukowanych
A. w roku 2017.
B. w latach innych niż 2017.
C. przed rokiem 2017.
D. po roku 2017.
Ta klauzula wybiera przedmioty wyprodukowane po roku 2017, czyli od 2018 wzwyż, przy typowym założeniu, że lata są z zakresu 2000–2099. Funkcja SUBSTR(rok_produkcji, 3, 2) pobiera z wartości roku dwa znaki od trzeciej pozycji. Dla roku 2017 wynikiem będzie 17, dla 2018 będzie 18, dla 2020 będzie 20, a dla 2005 będzie 05. Warunek > 17 odrzuca więc rok 2017 i lata wcześniejsze w tym stuleciu, a zostawia 2018, 2019, 2020 itd. W MySQL, jeśli rok_produkcji jest liczbą, system i tak zwykle dokona konwersji na tekst przy użyciu SUBSTR, a potem porówna wynik liczbowo. Moim zdaniem w praktycznej bazie danych lepszym i czytelniejszym zapisem byłoby po prostu WHERE rok_produkcji > 2017, bo baza może wtedy łatwiej użyć indeksu i zapytanie jest bardziej zrozumiałe dla programisty. Takie operacje na fragmentach tekstu przydają się jednak np. przy analizie kodów produktów, numerów seryjnych albo dat zapisanych jako tekst, choć przy datach lepiej trzymać się typów DATE, YEAR lub liczbowych.
Niepoprawne odpowiedzi wynikają najczęściej z pomylenia działania funkcji SUBSTR z porównaniem całego roku. W tym zapytaniu nie jest sprawdzane bezpośrednio, czy rok_produkcji jest równy 2017, różny od 2017 albo mniejszy od 2017. Najpierw z wartości roku pobierane są dwa znaki zaczynając od trzeciej pozycji. Dla zapisu 2017 są to znaki 17, dla 2016 znaki 16, a dla 2018 znaki 18. Dopiero ten wycięty fragment jest porównywany z liczbą 17. Z tego powodu rok 2017 nie spełnia warunku, bo 17 > 17 jest fałszem. Lata wcześniejsze, takie jak 2001, 2009 czy 2016, również nie przejdą, bo dają odpowiednio 01, 09, 16, czyli wartości nie większe od 17. Stwierdzenie, że zapytanie zwróci lata inne niż 2017, też jest mylące, bo wtedy powinien wystąpić operator <> albo !=, a nie >. Typowy błąd polega tu na czytaniu warunku „na oko”, bez rozbicia go na etapy: najpierw funkcja tekstowa, potem konwersja lub porównanie, potem filtr WHERE. Z mojego doświadczenia warto też uważać na takie zapytania w prawdziwych projektach, bo operowanie funkcją na kolumnie może utrudnić użycie indeksu. Dobra praktyka SQL mówi, żeby do filtrowania lat używać prostszego warunku rok_produkcji > 2017, o ile kolumna faktycznie przechowuje rok jako liczbę lub poprawny typ daty.