Poprawna jest kwerenda: UPDATE pracownicy SET plec='K' WHERE imie LIKE '%a';. Po pierwsze użyty jest właściwy typ polecenia SQL do modyfikacji danych w tabeli. Do zmiany wartości w istniejących rekordach zawsze używamy instrukcji UPDATE, a nie ALTER TABLE. ALTER TABLE służy do zmiany struktury tabeli (np. dodanie kolumny, zmiana typu danych, usunięcie kolumny), a nie do operowania na danych w wierszach. To jest taki podstawowy podział: DDL (Data Definition Language) – np. ALTER TABLE, CREATE, DROP – do definicji struktury; DML (Data Manipulation Language) – np. SELECT, INSERT, UPDATE, DELETE – do pracy na rekordach. W tym zadaniu ewidentnie potrzebna jest operacja DML.
Druga ważna rzecz to warunek WHERE imie LIKE '%a'. Operator LIKE służy do porównywania tekstów z wykorzystaniem wzorców. Symbol % oznacza „dowolny ciąg znaków (również pusty)”, więc wzorzec '%a' oznacza: dowolny ciąg znaków zakończony literą „a”. Dokładnie o to chodzi w zadaniu: przyjmujemy założenie, że każde imię żeńskie kończy się na „a”, więc chcemy zaktualizować wszystkie rekordy, gdzie kolumna imie kończy się na „a”. Gdybyśmy chcieli szukać imion zaczynających się na „A”, używalibyśmy 'A%'.
Moim zdaniem warto zapamiętać ten schemat, bo w praktyce bardzo często stosuje się LIKE do prostych filtrów tekstowych: wyszukiwanie użytkowników po fragmencie loginu, znajdowanie produktów po części nazwy, filtrowanie adresów e-mail po domenie itp. Przykład: UPDATE klienci SET status='VIP' WHERE nazwisko LIKE 'Nowak%'; – zaktualizuje wszystkich Nowaków. Albo: UPDATE produkty SET promocja=1 WHERE nazwa LIKE '%kabel%'; – zaznaczy jako promocyjne wszystkie produkty, których nazwa zawiera słowo „kabel”. W dobrych praktykach zaleca się uważać z aktualizacjami bez WHERE, bo wtedy zmieniamy wszystkie rekordy w tabeli. Tutaj warunek LIKE '%a' pełni rolę bezpiecznego filtra. W wielu systemach bazodanowych warto też pamiętać, że domyślnie porównania tekstowe mogą być niewrażliwe na wielkość liter (collation), więc 'a' i 'A' mogą być traktowane tak samo, ale to już zależy od konfiguracji bazy. W kontekście egzaminów zawodowych i pracy z SQL-em takie zadanie to klasyk – łączy poprawne użycie UPDATE z właściwym użyciem LIKE i symbolu % jako wieloznakowego wildcarda.
W tym zadaniu łatwo się potknąć na dwóch rzeczach: pomyleniu operacji na strukturze tabeli z operacjami na danych oraz na nieprawidłowym użyciu wzorca tekstowego. W SQL istnieje dość wyraźny podział na instrukcje służące do definiowania struktury bazy (DDL) oraz te, które manipulują rekordami (DML). ALTER TABLE należy do tej pierwszej grupy. Używa się go do dodawania kolumn, zmiany typu danych, ustawiania kluczy obcych, czasem indeksów. Nie ma on mechanizmu typu SET kolumna='wartość' z warunkiem WHERE, który modyfikuje poszczególne wiersze. Próba napisania ALTER TABLE ... SET plec='K' WHERE imie LIKE '%a' po prostu nie jest zgodna ze składnią SQL i nie zadziała w żadnym normalnym systemie bazodanowym.
Drugi typ błędu dotyczy użycia WHERE imie='%a'. W wielu językach programowania znak % kojarzy się z operacjami na łańcuchach albo z formatowaniem, ale w czystym SQL porównanie z operatorem = oznacza ścisłą równość, bez żadnych wildcardów. Wyrażenie imie = '%a' oznacza: imie ma być dokładnie dwuznakowym ciągiem składającym się z procenta i litery „a”. Żadne „dowolne znaki przed a” się tu nie pojawiają. Do dopasowywania wzorców tekstowych służy operator LIKE, a dopiero przy LIKE znaczek % ma specjalne znaczenie – „dowolny ciąg znaków”. To jest bardzo typowe nieporozumienie: ktoś pamięta, że w LIKE używa się % i _ jako wildcardów, i odruchowo wrzuca % także przy zwykłym =.
Z mojego doświadczenia wynika, że dobrym nawykiem jest rozdzielenie w głowie: UPDATE + SET + WHERE – do zmiany danych; ALTER TABLE – tylko do zmian struktury. A przy wyszukiwaniu tekstów: jeśli chcę sztywne porównanie, używam =, jeśli szukam po fragmencie, używam LIKE z % (wieloznak) lub _ (pojedynczy znak). W praktyce webowej błędne użycie tych konstrukcji może prowadzić do sytuacji, że kwerenda nic nie zwraca albo nie aktualizuje żadnego rekordu, a programista długo szuka błędu np. po stronie PHP czy JavaScript, zamiast zacząć od samego SQL-a. Warto też pamiętać, że aktualizacje bez poprawnego WHERE są niebezpieczne, bo mogą zmienić wszystkie rekordy w tabeli, więc warunek oparty na właściwie użytym LIKE jest kluczowy zarówno dla poprawności, jak i bezpieczeństwa danych.