Prawidłowa kwerenda używa instrukcji UPDATE z klauzulą SET oraz warunkiem w części WHERE: „UPDATE studenci SET ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;”. To dokładnie odpowiada temu, co chcemy zrobić: zaktualizować istniejące rekordy w tabeli, tylko w tych wierszach, gdzie kolumna ubezpieczenie ma wartość NULL. UPDATE służy właśnie do modyfikowania danych w tabeli, a nie do zmiany jej struktury. Kluczowy jest tu warunek WHERE ubezpieczenie IS NULL – bez tego zmienilibyśmy wartość ubezpieczenie na „brak” we wszystkich wierszach, co byłoby poważnym błędem. W SQL porównanie z NULL odbywa się zawsze przez IS NULL lub IS NOT NULL, a nie przez operator =, bo NULL oznacza „brak danych”, a nie konkretną wartość. Moim zdaniem warto zapamiętać ten schemat, bo w praktyce pracy z bazami danych bardzo często trzeba „sprzątać” dane: zastępować wartości NULL jakimiś domyślnymi opisami, np. „nieznany”, „nie dotyczy”, „brak danych”. Przykładowo: UPDATE klienci SET telefon='brak' WHERE telefon IS NULL; albo UPDATE pracownicy SET premia=0 WHERE premia IS NULL;. To jest ten sam wzorzec działania. Dobrą praktyką jest też najpierw wykonać SELECT z tym samym warunkiem WHERE, żeby zobaczyć, które rekordy zostaną zmodyfikowane, zanim puścimy właściwy UPDATE. W projektowaniu baz danych przyjęło się, że UPDATE służy do zmiany zawartości wierszy, a ALTER TABLE do zmiany struktury tabeli (dodawanie kolumn, zmiana typów, kluczy itp.). Mieszanie tych dwóch ról prowadzi potem do dziwnych błędów. W standardowym SQL nie ma możliwości aktualizacji tylko części wierszy poprzez ALTER TABLE, dlatego tutaj jedynym sensownym, poprawnym i zgodnym z dobrymi praktykami rozwiązaniem jest właśnie użycie UPDATE z warunkiem WHERE ubezpieczenie IS NULL.
W tym zadaniu łatwo wpaść w kilka typowych pułapek związanych z rozumieniem różnicy między modyfikacją danych a modyfikacją struktury tabeli. W SQL mamy dwa zupełnie różne światy: polecenia typu UPDATE, DELETE, INSERT działają na rekordach, czyli na zawartości tabeli, natomiast ALTER TABLE służy do zmiany schematu – dodawania kolumn, zmiany typów, ustawiania ograniczeń. Próba użycia ALTER TABLE do modyfikowania konkretnych wartości w wybranych wierszach po prostu nie pasuje do logiki języka SQL. Jeśli w poleceniu pojawia się ALTER TABLE z klauzulą ADD i jednocześnie WHERE, to widać tu pomieszanie pojęć. ADD dodaje nową kolumnę lub ograniczenie do całej tabeli, nie ma możliwości, żeby ALTER TABLE działał tylko na wierszach spełniających jakiś warunek. Warunek WHERE jest typowy dla operacji na danych (SELECT, UPDATE, DELETE), a nie na strukturze. Podobnie MODIFY COLUMN w SQL służy do zmiany typu, rozmiaru lub właściwości kolumny (np. z NULL na NOT NULL, zmiana długości VARCHAR), ale nie do ustawiania konkretnej wartości tekstowej w wybranych rekordach. Ustawienie NOT NULL bez zrozumienia aktualnej zawartości kolumny jest zresztą ryzykowne – jeżeli w tabeli są jakieś wartości NULL, baza może w ogóle nie przyjąć takiej zmiany albo wymagać wartości domyślnej, ale to nadal nie oznacza, że te NULL-e zostaną zamienione na sensowny ciąg znaków. Czasem pojawia się też błąd składniowy polegający na pominięciu słowa SET przy UPDATE albo błędnym umieszczeniu warunku IS NULL. Standard SQL wymaga postaci: UPDATE nazwa_tabeli SET kolumna=wartość WHERE warunek;. Próba napisania UPDATE studenci ubezpieczenie IS NULL SET ubezpieczenie='brak'; łamie tę strukturę – parser SQL nie jest w stanie tego poprawnie zinterpretować, bo po nazwie tabeli nie może stać od razu warunek, tylko ewentualny alias, a potem musi być słowo SET. Z mojego doświadczenia wynika, że wiele osób myli kolejność elementów w zapytaniu, zwłaszcza gdy łączy warunki z modyfikacją danych. Podsumowując, żeby zamienić wartości NULL na ciąg znaków „brak” w konkretnej kolumnie, potrzebne jest czyste UPDATE z prawidłową składnią i z warunkiem WHERE ubezpieczenie IS NULL. ALTER TABLE nie nadaje się do takiej operacji, a pominięcie SET albo błędne użycie IS NULL skutkuje albo błędem składni, albo niepoprawnym działaniem. Dobra praktyka w pracy z bazami danych to wyraźne oddzielanie operacji na strukturze od operacji na danych i dokładne pilnowanie składni w tego typu poleceniach.