Чем обычное представление отличается от таблицы, почему оно выглядит как таблица и когда удобен каждый вариант.
Один и тот же отчёт каждый день
Представим условную команду продаж. Сведения о заказах хранятся в одной таблице, названия товаров — в другой. Сотрудникам нужен привычный список, где рядом видны заказ и товар. Можно каждый раз заново формулировать правило объединения, а можно дать этому правилу имя и обращаться к нему как к готовому представлению.
Таблица и представление внешне могут быть похожи: оба показывают строки и столбцы. Но при разговоре о хранении важно различать сам набор записей и способ увидеть их через сохранённое правило. Речь здесь об обычном представлении; материализованные варианты устроены иначе и требуют отдельного объяснения.
Таблица хранит записи
В обычной таблице база данных хранит строки: условный номер заказа, дату и сумму. Столбцы описывают, какие сведения ожидаются. Записи могут добавляться и меняться по правилам системы. Если источник ошибся в сумме, ошибка окажется в таблице; одно лишь удобное отображение её не исправит.
Таблицу можно представить как картотеку. Однако сравнение имеет границы: база данных умеет проверять допустимость значений, связывать таблицы и выбирать разные способы чтения. Для вопроса о представлении главное, что таблица содержит собственные сохранённые данные, к которым обращаются другие объекты.
Представление сохраняет способ посмотреть на данные
Обычное представление задаёт именованный способ получить нужные строки и столбцы из одной или нескольких таблиц. Пользователь может обращаться к нему почти как к таблице, но видимый набор строится по определению представления. Документация PostgreSQL показывает такой приём для повторяющегося объединения данных и отмечает, что представление скрывает от потребителя детали структуры исходных таблиц.
В нашем условном случае представление может показывать заказ вместе с названием товара. Если название исправили в исходной таблице, следующий просмотр обычного представления опирается на актуальные исходные данные. Это не самостоятельная копия списка, которую кто-то обязан вручную переписать.
Когда различие важно
Представление удобно, когда многим людям нужен один согласованный способ видеть данные. Например, команда может договориться показывать только завершённые заказы и одинаково трактовать отмены. Но определение представления тоже нужно поддерживать: изменение исходной таблицы или смысла статуса может повлиять на результат.
Не стоит считать обычное представление автоматически быстрым или безопасным. Сложный способ получения данных способен работать медленно, а доступ к чувствительным сведениям зависит от настроенных прав и определения. Если результат нужно хранить отдельно для повторного чтения, рассматривают другие варианты, включая подготовленные таблицы или материализованные представления.
Как объяснить выбор коллеге
Спросите, что должно оставаться сохранённым: сами записи или правило их просмотра. Если требуется записывать новые заказы, нужна таблица. Если нужно многократно показывать согласованный срез уже существующих данных, может подойти представление. Для устойчивого отчёта дополнительно уточните частоту обновления исходных таблиц и допустимую задержку.
Полезно записать определение результата человеческими словами: какие заказы попадают в список и почему. Тогда даже без знания устройства базы люди смогут проверить, отвечает ли представление их задаче. Название объекта не заменяет описание бизнес-смысла.
Проверка на условном примере
Предположим, в таблице товаров записано новое название позиции. Обычное представление, которое показывает продажи вместе с названиями товаров, при следующем обращении использует обновлённый источник. Но уже выгруженный из него вчерашний файл сам по себе не изменится: это отдельная сохранённая копия результата.
Путаница возникает, когда словом «представление» называют и экран приложения, и объект базы данных. В этой статье речь только об объекте базы. Его правила стоит документировать, чтобы коллеги не принимали видимый список за независимый источник истины.
По теме
Следующий шаг
Если хотите развить навыки в этой области, посмотрите SQL инженер и сопоставьте программу со своими задачами. Материал помогает понять отдельный вопрос, но не заменяет практику и обсуждение конкретной ситуации с вашей командой.
