🗄️ SQL и базы данных · 20 вопросов · ~35 мин · ⏱ Таймер 35:00 · Лёгкий ·

Добавление, изменение и удаление данных

Изменяющие запросы оцениваются по реальному эффекту: какие строки будут вставлены, что произойдёт при конфликте, как NULL и условие WHERE влияют на UPDATE, почему DELETE без фильтра опасен и что именно возвращает RETURNING. В задачах есть предварительные проверки, массовые изменения и случаи, где внешне удобный запрос повреждает больше данных, чем планировалось.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 35 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Почему явный список столбцов безопаснее?

INSERT INTO customers (name, email)
VALUES ('Анна', 'a@example.com');

Он делает INSERT быстрее во всех случаях Без него нельзя вставлять числа Значения явно привязаны к полям и их порядку Он отключает ограничения

Вопрос 2 из 20

Сколько строк пытается вставить команда?

INSERT INTO tags(name) VALUES
 ('sql'),
 ('postgresql'),
 ('database');

2 3 Зависит от числа столбцов 1

Вопрос 3 из 20

Что произойдёт с omitted created_at, если столбец имеет DEFAULT now() и не указан в INSERT?

created_at получит значение соседнего столбца email из той же строки created_at станет NULL, даже если объявлено DEFAULT now() created_at получит DEFAULT now(), потому что столбец не указан в INSERT INSERT завершится ошибкой, потому что столбец с DEFAULT всё равно обязателен в списке

Вопрос 4 из 20

Почему запрос может нарушить UNIQUE(email)?

INSERT INTO customers(name,email)
VALUES ('Новая Анна','a@example.com');

В таблице уже может существовать такой email UNIQUE(email) проверяется лишь тогда, когда name тоже является ключом VALUES допускает только числовые литералы, а email содержит текст При совпадении email обычный INSERT неявно заменит старую строку новой

Вопрос 5 из 20

Как вставить результат SELECT в архив с совпадающим списком столбцов?

SELECT id, created_at
INTO archive
FROM orders
WHERE status = 'done';

INSERT INTO archive (id, created_at)
VALUES (SELECT id, created_at FROM orders WHERE status = 'done');

INSERT INTO archive (id, created_at)
SELECT id, created_at
FROM orders
WHERE status = 'done';

UPDATE archive
SET (id, created_at) = (SELECT id, created_at FROM orders WHERE status = 'done');

Вопрос 6 из 20

Что случится без WHERE?

UPDATE products
SET price = price * 1.1;

СУБД автоматически потребует подтверждение UPDATE ничего не сделает Обновятся все строки таблицы Обновится первая строка

Вопрос 7 из 20

Как изменится NULL price в выражении price = price * 1.1?

Станет 1.1 Станет 0 Останется NULL Вся команда завершится ошибкой

Вопрос 8 из 20

Как сделать повышение только для активных товаров категории 5?

UPDATE products SET price=price*1.1 WHERE active=true AND category_id=5; UPDATE products SET price=1.1; UPDATE products SET active=true, category_id=5; UPDATE products WHERE active=true SET price=price*1.1 OR category_id=5;

Вопрос 9 из 20

Почему SET discount = discount + 10 может быть неидемпотентным?

UPDATE нельзя запускать дважды WHERE исчезнет discount станет текстом Каждый повтор снова увеличит скидку

Вопрос 10 из 20

Перед выполнением этого массового UPDATE какой SELECT лучше всего проверит затрагиваемые строки?

UPDATE products
SET price = price * 1.1
WHERE category_id = 5 AND active = true;

SELECT id, price FROM products WHERE active=true; SELECT id, price FROM products WHERE category_id=5 OR active=true; SELECT id, price FROM products WHERE category_id=5 AND active=true; SELECT id, price FROM products WHERE category_id=5;

Вопрос 11 из 20

Что удалит команда без WHERE?

DELETE FROM orders;

Саму таблицу и схему Ничего без COMMIT Все строки orders, но не саму таблицу Только строку с минимальным id

Вопрос 12 из 20

Как удалить клиентов, у которых нет заказов, устойчиво к NULL?

DELETE FROM customers c USING orders o WHERE o.customer_id <> c.id;DELETE orders FROM customers; DELETE FROM customers c WHERE c.id IS NULL OR c.id = 0;DELETE FROM customers WHERE id=NULL; DELETE FROM customers c WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id=c.id); DELETE FROM customers c WHERE c.id NOT IN (SELECT customer_id FROM orders);DELETE FROM customers WHERE id NOT IN (SELECT customer_id FROM orders);

Вопрос 13 из 20

Что может помешать удалить клиента с заказами?

Наличие индекса на email DEFAULT у created_at Внешний ключ без подходящего ON DELETE ORDER BY в другой таблице

Вопрос 14 из 20

Чем DELETE отличается от DROP TABLE?

DELETE и DROP удаляют одинаковые данные, различается только журналирование DROP можно откатить в транзакции, а DELETE фиксируется сразу и необратимо DELETE удаляет выбранные столбцы, а DROP TABLE оставляет строки без схемы DELETE удаляет строки, DROP удаляет сам объект таблицы

Вопрос 15 из 20

Какой фильтр удалит только временные строки старше 30 дней?

DELETE FROM sessions WHERE temporary=true AND created_at < CURRENT_DATE - INTERVAL '30 days'; DELETE FROM sessions WHERE temporary=true OR created_at < CURRENT_DATE - INTERVAL '30 days'; DELETE FROM sessions LIMIT 30; DELETE FROM sessions WHERE created_at=NULL;

Вопрос 16 из 20

Что даёт RETURNING id после INSERT?

INSERT INTO customers(name) VALUES ('Ирина')
RETURNING id;

Идентификаторы реально вставленных строк Только число столбцов Все старые id таблицы План выполнения

Вопрос 17 из 20

Какие строки вернёт RETURNING в этом UPDATE?

UPDATE products
SET price = round(price * 1.10, 2)
WHERE category_id = 5
RETURNING id, price;

Только строки, у которых округлённая цена численно отличается от прежней Ни одной строки до отдельного COMMIT, выполненного следующим запросом Все товары таблицы, потому что RETURNING выполняется после SET Все строки категории 5, обработанные этим UPDATE

Вопрос 18 из 20

Зачем выполнять рискованное изменение внутри BEGIN перед COMMIT?

Можно проверить результат и выполнить ROLLBACK, пока транзакция не зафиксирована Перед первым изменением BEGIN автоматически сохраняет прежние версии в отдельной резервной таблице BEGIN делает изменения невидимыми даже текущему сеансу до COMMIT BEGIN позволяет увидеть RETURNING, но не применяет UPDATE к строкам до COMMIT

Вопрос 19 из 20

Какой порядок действий безопаснее для массового исправления?

BEGIN → SELECT id ... FOR UPDATE и сохранить список id → UPDATE ... WHERE id = ANY(:ids) RETURNING → проверка → COMMIT или ROLLBACK BEGIN → SELECT id по условию → UPDATE с тем же WHERE RETURNING → проверка → COMMIT или ROLLBACK BEGIN → UPDATE по условию RETURNING → COMMIT → проверка результата после фиксации BEGIN → SELECT id ... FOR UPDATE и сохранить список → COMMIT → отдельный UPDATE сохранённых id

Вопрос 20 из 20

Почему проверка только сообщения «UPDATE 1000» недостаточна?

Счётчик содержит идентификаторы затронутых строк, но не показывает их новые значения Число строк не показывает, именно те ли записи изменены и верны ли новые значения Точное число строк становится известно только после отдельного COMMIT Счётчик включает только строки, у которых новое значение отличается от прежнего

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу