Как изменить фамилию в таблице SQL

Что проверяют

Синтаксис UPDATE знают почти все, поэтому смотрят на аккуратность: как вы гарантируете, что изменится ровно одна строка. Следом спрашивают, как проверить результат и что делать, если запрос задел лишнее.

Как отвечать

Базовый запрос: UPDATE employees SET last_name = 'Петрова' WHERE id = 42;

Дальше покажите порядок, в котором вы меняете общие данные:

• сначала SELECT: тем же условием SELECT * FROM employees WHERE id = 42; убедиться, что находится одна нужная запись;
• фильтр по первичному ключу: условие WHERE last_name = 'Иванова' заденет всех однофамильцев, а id уникален;
• транзакция: BEGIN;, затем UPDATE, проверка числа затронутых строк, которое база пишет в ответе (UPDATE 1 в PostgreSQL), и только потом COMMIT или ROLLBACK;
• проверка результата: в PostgreSQL удобно UPDATE ... RETURNING id, last_name, в других базах повторный SELECT.

Детали синтаксиса, которые стоит знать:

• строки: пишутся в одинарных кавычках, апостроф внутри удваивается: 'О''Нил';
• данные из другой таблицы: в PostgreSQL для этого есть UPDATE ... FROM, в MySQL UPDATE ... JOIN;
• побочные эффекты: триггеры и поля аудита вроде updated_at для тестировщика тоже часть ожидаемого результата.

В работе QA такой запрос нужен в двух ситуациях: подготовить тестовые данные и проверить, что смена фамилии через интерфейс или API действительно дошла до базы, а не осталась в кэше.

Где спотыкаются

Запускают UPDATE без WHERE или с условием по фамилии. В DBeaver и psql по умолчанию включён автокоммит, так что откатывать уже нечего. В MySQL от части таких ошибок страхует режим sql_safe_updates.

Берут значение в двойные кавычки. В PostgreSQL "Петрова" означает имя колонки, и запрос падает с ошибкой, что такой колонки не существует.

Правят данные на общем стенде, не предупредив команду, и ломают чужие автотесты, завязанные на эти записи. Надёжнее заводить собственные тестовые записи или менять их через API.