В чем разница операторов UPDATE и INSERT в SQL

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

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

Как отвечать

Суть в одном предложении: INSERT создаёт новые строки, UPDATE меняет значения в существующих. Дальше детали, которые показывают опыт:

• INSERT: INSERT INTO users (email, name) VALUES ('a@b.ru', 'Анна'). Столбцы без значения получают DEFAULT или NULL, идентификатор обычно генерирует база через IDENTITY или последовательность. Можно вставить результат выборки: INSERT INTO ... SELECT ...;
• UPDATE: UPDATE users SET name = 'Ольга' WHERE id = 42. Условие WHERE синтаксически необязательно, и без него обновятся все строки таблицы. Число строк UPDATE не меняет никогда;
• ограничения: обе команды проверяются по PRIMARY KEY, UNIQUE, NOT NULL, FOREIGN KEY и CHECK, поэтому и UPDATE может упасть на дубликате;
• upsert: для «вставить или обновить» в PostgreSQL есть INSERT ... ON CONFLICT DO UPDATE, в MySQL ON DUPLICATE KEY UPDATE, во многих СУБД стандартный MERGE.

Для тестирования важна одна деталь: UPDATE, который не нашёл ни одной строки, ошибки не выдаёт, база просто сообщает, что затронуто 0 строк. Если приложение не смотрит на это число, пользователь увидит «сохранено», хотя ничего не изменилось. Хорошая привычка: перед UPDATE выполнить SELECT с тем же WHERE, а на общем стенде работать внутри BEGIN и при сомнении делать ROLLBACK.

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

Говорят, что UPDATE требует WHERE. Не требует, и именно поэтому забытое условие на общем стенде портит данные всей команде.

Путают UPDATE с ALTER TABLE. Первая команда меняет данные в строках, вторая меняет структуру таблицы, это уже DDL.

Считают, что UPDATE несуществующей записи вернёт ошибку. Так пропускают баги, когда API отвечает 200 на изменение объекта, которого нет.