Какой синтаксис update в SQL
Что проверяют
Умеете ли вы сами готовить и менять тестовые данные, не дёргая разработчиков, и насколько аккуратно обращаетесь с общей базой. Синтаксис знают почти все, поэтому следом спрашивают, как убедиться, что обновились именно нужные строки, и как обновить таблицу по данным из другой.
Как отвечать
Базовая форма одна для всех СУБД: UPDATE orders SET status = 'cancelled', updated_at = now() WHERE id = 1042;
- SET: пары «колонка = выражение» через запятую. Можно ссылаться на старое значение:
SET price = price * 0.9; - WHERE: какие строки менять. Без него обновится вся таблица, и СУБД не переспросит;
- обновление по другой таблице: здесь диалекты расходятся. В PostgreSQL это
UPDATE ... SET ... FROM t2 WHERE ..., в MySQLUPDATE t1 JOIN t2 ON ... SET ..., в SQL ServerUPDATE ... SET ... FROM ... JOIN ...; - RETURNING: в PostgreSQL сразу возвращает изменённые строки, удобно для проверки.
Покажите и рабочий порядок. Сначала SELECT с тем же WHERE, чтобы увидеть, сколько строк попадёт под условие. Потом BEGIN, UPDATE, сверка числа затронутых строк и только затем COMMIT или ROLLBACK. Многие клиенты по умолчанию работают в режиме автокоммита, и без явной транзакции ошибку уже не откатить. В MySQL есть режим sql_safe_updates, который не даёт выполнить UPDATE без условия по ключу.
Для тестировщика стоит сказать и зачем это нужно: перевести заказ в редкий статус, сдвинуть дату подписки, чтобы проверить истечение, вернуть стенд в исходное состояние после прогона.
Где спотыкаются
Пишут WHERE column = NULL. Такое сравнение никогда не даёт истину, нужно IS NULL, и запрос молча обновит ноль строк.
Меняют данные на общем стенде без транзакции и без записи о том, что было до изменения. Коллеги получают сломанные сценарии, а вернуть старые значения уже не из чего.
Забывают, что прямой UPDATE обходит логику приложения: не пишется история статусов, не сбрасывается кеш, не уходят события в очередь. Баг, найденный на таких данных, может оказаться артефактом самой подмены.