🗄️ SQL и базы данных · 20 вопросов · ~38 мин · ⏱ Таймер 38:00 · Средний ·

Представления и материализованные представления

Вопросы проверяют, что именно хранит VIEW, когда результат пересчитывается, почему материализованное представление устаревает до REFRESH, какие простые представления могут обновляться, как WITH CHECK OPTION удерживает строки в видимой области и где представление помогает выдавать ограниченный набор столбцов, но не отменяет продуманную модель прав.

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

⏱ --:--

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

Вопрос 1 из 20

Что хранит обычное VIEW?

CREATE VIEW active_users AS
SELECT id, name FROM users WHERE active;

Физическую копию базовой таблицы, включая строки, не прошедшие условие представления Определение запроса, выполняемого при обращении Снимок подходящих строк на момент CREATE VIEW, который обновляется при новом подключении Только имена и типы выходных столбцов; исходное выражение и фильтры не сохраняются

Вопрос 2 из 20

Увидит ли VIEW новую строку базовой таблицы при следующем SELECT, если она подходит условию?

Да, запрос представления выполняется снова Только после сброса кеша плана или нового подключения к базе Нет, пока администратор не выполнит отдельную команду REFRESH VIEW Только после ANALYZE базовой таблицы, даже если строка уже зафиксирована

Вопрос 3 из 20

Можно ли передать параметр обычному VIEW как функции?

CREATE VIEW recent_orders AS
SELECT * FROM orders WHERE created_at >= current_date - 30;

Да, через ORDER BY Нет, параметры требуют запроса или функции Только параметр id Да, синтаксис SELECT * FROM view(10) стандартен для любого VIEW

Вопрос 4 из 20

Гарантирует ли SELECT из VIEW порядок, если внешний запрос не содержит ORDER BY?

Да, внутренний ORDER BY остаётся обязательным порядком для любого внешнего запроса Нет, полагаться можно только на ORDER BY итогового запроса Да, если определение VIEW содержит ORDER BY и LIMIT Да, если у базовой таблицы есть первичный ключ, совпадающий с внутренней сортировкой

Вопрос 5 из 20

Почему при создании публичного VIEW опасно выбирать все текущие столбцы users через SELECT *?

CREATE VIEW public_users AS SELECT * FROM users;

В интерфейс сразу попадут все текущие столбцы, включая служебные или чувствительные При каждом чтении VIEW звёздочка заново добавляет все столбцы, появившиеся в users после создания VIEW Права на VIEW автоматически дают роли прямой SELECT ко всей таблице users Звёздочка меняет порядок строк и тем самым раскрывает последовательность создания пользователей

Вопрос 6 из 20

Что хранит материализованное представление?

CREATE MATERIALIZED VIEW monthly_sales AS
SELECT date_trunc('month', created_at) m, SUM(amount) total
FROM orders GROUP BY 1;

Список транзакций Физически сохранённый результат запроса Только текст запроса Только права доступа

Вопрос 7 из 20

Увидит ли materialized view только что добавленный заказ до REFRESH?

INSERT INTO orders(id, status) VALUES (501, 'paid');
SELECT * FROM monthly_sales; -- materialized view

Новая строка появится только при INSERT RETURNING, даже без REFRESH Да: materialized view перечитывает базовые таблицы при каждом SELECT Материализация обновится автоматически только для строк со status = paid Нет, сохранённый результат останется прежним

Вопрос 8 из 20

Что делает REFRESH MATERIALIZED VIEW?

REFRESH MATERIALIZED VIEW monthly_sales;

Обновляет только статистику планировщика, не меняя сохранённый результат REFRESH переносит строки в материализованное представление и очищает их из базовых таблиц Преобразует материализованное представление в обычное VIEW без сохранённых строк Заново вычисляет и заменяет сохранённый результат

Вопрос 9 из 20

Зачем может понадобиться REFRESH ... CONCURRENTLY?

Чтобы по возможности сохранить чтение старой версии во время обновления Чтобы преобразовать обычное VIEW в физическую таблицу без пересоздания Чтобы каждый SELECT автоматически запускал полное обновление результата Чтобы обновлять материализацию без уникального индекса на её строках

Вопрос 10 из 20

Почему для CONCURRENTLY нужен подходящий уникальный индекс PostgreSQL?

Без уникального индекса агрегаты в новой версии вычисляются неверно Он позволяет однозначно сопоставлять строки старой и новой версии при конкурентной замене Уникальный индекс нужен только для сортировки строк перед REFRESH Индекс хранит расписание обновления и предотвращает слишком частый REFRESH

Вопрос 11 из 20

Какое VIEW вероятнее всего автоматически обновляемо в PostgreSQL?

CREATE VIEW v AS SELECT department_id,COUNT(*) FROM employees GROUP BY department_id; CREATE VIEW v AS SELECT DISTINCT email FROM users; CREATE VIEW v AS SELECT * FROM a JOIN b ON b.a_id=a.id; CREATE VIEW v AS SELECT id,name FROM users WHERE active;

Вопрос 12 из 20

Почему UPDATE агрегированного VIEW неоднозначен?

CREATE VIEW dept_totals AS
SELECT department_id, SUM(salary) total
FROM employees GROUP BY department_id;

Агрегированный VIEW обновляем, если каждая группа содержит хотя бы одну строку Итог соответствует многим строкам, способ изменения неясен GROUP BY удаляет связь результата с базовой таблицей только при наличии HAVING UPDATE может менять только текстовые столбцы VIEW, но не числовые итоги

Вопрос 13 из 20

Что делает WITH CHECK OPTION у фильтрующего VIEW?

CREATE VIEW active_users AS
SELECT * FROM users WHERE active
WITH CHECK OPTION;

Проверяет условие VIEW только при чтении, но не влияет на INSERT и UPDATE Не позволяет записать через VIEW строку, которая не удовлетворяет его условию Запрещает изменять базовую таблицу напрямую в обход этого VIEW Не позволяет существующим строкам исчезать из результата после изменений в базовой таблице

Вопрос 14 из 20

Можно ли удалить строку через простое обновляемое VIEW?

Только если у VIEW есть уникальный индекс, как у материализованного представления Да, если представление обновляемо и операция однозначно отображается на базовую таблицу Да, но удаляется лишь строка результата VIEW, а базовая таблица не меняется DELETE через VIEW недоступен, хотя INSERT и UPDATE для того же представления могут быть разрешены

Вопрос 15 из 20

Для чего нужен INSTEAD OF trigger на сложном VIEW?

Триггер нужен для ускорения каждого SELECT независимо от сложности представления Чтобы явно реализовать, как DML на представлении преобразуется в изменения базовых таблиц INSTEAD OF trigger превращает сложное VIEW в физически хранимый результат при первом DML INSTEAD OF trigger отменяет права владельца на базовые таблицы

Вопрос 16 из 20

Как VIEW может ограничить раскрываемые столбцы?

CREATE VIEW support_customers AS
SELECT id, name, status FROM customers;
GRANT SELECT ON support_customers TO support_role;

Скрыть имена через комментарии Использовать SELECT * Показать только выбранные поля через VIEW Добавить ORDER BY

Вопрос 17 из 20

Достаточно ли просто создать VIEW для безопасности?

Нет, нужно настроить права, владельца/режим выполнения и проверить обходные пути Да: наличие VIEW само по себе закрывает прямой доступ к базовым таблицам Нет: любой VIEW автоматически доступен PUBLIC, и изменить это нельзя Да, если имя представления начинается с secure и не содержит SELECT *

Вопрос 18 из 20

Почему функция с побочными эффектами внутри VIEW требует особой осторожности?

Побочный эффект делает SELECT быстрее, поэтому риск связан только с нагрузкой Функции можно использовать в обычном SELECT, но синтаксически нельзя во VIEW Функция с побочным эффектом выполняется только при REFRESH, как в материализованном представлении SELECT из VIEW может вызвать код с правами и поведением, которые не видны из списка столбцов

Вопрос 19 из 20

Как проверить, что роль не может увидеть salary через базовую таблицу?

Проверить запрос администратора и считать, что наследуемые права роли совпадают Выполнить тест под этой ролью и убедиться, что прямой SELECT запрещён, а разрешённый VIEW не содержит salary Удалить индекс по salary, потому что именно индекс открывает чтение столбца Переименовать salary во VIEW: после этого прямой доступ к базовой таблице не важен

Вопрос 20 из 20

Для чего материализованный отчёт с ограниченными правами всё равно требует контроля свежести?

Потому что ограничение прав отключает автоматический REFRESH представления Потому что материализация автоматически раскрывает все столбцы базовых таблиц Потому что свежесть влияет только на выбор индекса, но не на смысл отчёта Пользователь может получить корректно ограниченные, но устаревшие данные

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

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

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

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