Здравствуйте, уважаемые подписчики и гости канала!
Зачем все это?
VIEW (представления) в базах данных хорошо подходят для удовлетворения принципа инкапсуляции, т.е. через представления вы можете скрывать реализацию реальных таблиц, чтобы иметь возможность менять поля таблиц быстро.
Также они хорошо заходят, когда у вас есть старый кусок кода, в который вы не хотите лезть, но вам надо сильно поменять структуру таблицы, которую использует этот кусок. И вот, вы просто переименовываете исходную таблицу, проводите миграцию на ней (меняете схему и пр) и создаете VIEW с именем и схемой, как у старой таблицы.
Подборка видео всех видео по PG - https://dzen.ru/suite/37b67ffa-176d-493a-b1a8-4762f79e3753
Как это работает. Пример
Вы скажете, ок - покажи как работать с view. Показываю.
Вот у вас есть какая-то таблица с организациями:
и еще одна с сотрудниками в этих организациях:
Ну и например так случилось, что времени нет и для вашего коллеги из другой команды надо отдать что-то прям из БД, но во все таблицы вы пускать не хотите по каким-то причинам. Или вам надо отдать данные интегратору и тоже как-то максимально инкапсулировно, не делая никаких тормозных api (хотя я не против api, но не всегда они нужны).
Итак, например интегратору надо забрать от вас id, name сотрудника и название его организации, чтобы например в jira как-то выводить. Вы просто делаете VIEW:
И даете доступ только туда. Ну а куда вас заведет пусть инкапсуляции я не знаю, но далеко не уходите - вашим коллегам может быть очень сложно с этим разобраться.
Материализованные MATERIALIZED VIEW
В принципе это просто - если view выполняет реальный запрос каждый раз, когда идет запрос к view. То материализованные представления просто пересчитываются вами раз в некоторое время и работают по сути как таблицы.
Это очень удобно, чтобы подхачить и быстро решить вопрос с производительностью, но такая view в случае роста данных будет пересчитываться все дольше и дольше, даже в режиме конкурентности.
Пересчитать тоже можно по сути только всё разом. Блокировки всякие возникают. Как по мне минусов больше, чем плюсов, но если тупит прям здесь и сейчас, то это выход и очень полезный инструмент.
Короче говоря, мы у себя от них отказались так же быстро, как и ввели ) Все перевели на таблицы - они дают боле ожидаемое поведение. Могут включаться в другие VIEW, если надо, и обновляются на сколько точечно, на сколько вы сделаете.
Ограничения
Нельзя использовать VIEW внутри VIEW, иначе вы не сможете нормально менять исходную VIEW - придется делать DROP VIEW и потом CREATE VIEW.
Если добавляете поля, добавляйте их в конец и тогда можно использовать CREATE OR REPLACE VIEW. Если replace vew не работает, то делаем drop view и create view, но знайте, что на нагруженной БД это не всегда возможно, приведет к простою, блокировкам и всякому такому неприятному.
Фишки
То, что будет написано далее не надо юзать каждый день, надо понимать зачем вы это делаете и понимать последствия! Однако, возможно, это спасет ваш проект в экстренной ситуации.
В PostgreSQL, а вы возможно уже знаете, что я очень люблю эту базу данных, есть очень крутая тема, которую надо использовать с осторожностью - INSERT, UPDATE триггеры на VIEW. Подробнее вы можете почитать в документации от Postgres Pro. Суть в том, что VIEW может вести себя как таблица, но не давая доступа в таблицу напрямую. Я считаю, что тут или автоматизированно надо этим управлять или очень редко использовать или вообще не соваться, чтобы "просто попробовать прикрутить к новой фиче на проде".
Поскольку VIEW - это запрос, то вместе с LATERAL JOIN можно делать прозрачный и оптимизированный вызов хранимых процедур.
Использую ли лично я VIEW в работе и как же ORM?
Представления мы используем активно, проблем не имеем и радуемся, что такой инструмент есть. Используем и в PostgreSQL и в BigQuery.
Я не люблю ORM и он мне никогда особо не помогал, а на старых проектах просто мешает. Скорее всего это сказывается специфика проектов, над которыми я работаю, но нам orm, так получилось, не нужен.
Так же стоит отметить, что orm часто генерируют мало нормальных запросов, а когда ваш проект становится нагруженным вы не можете быстро оптимизировать нужные места кода, так как код ORM у вас "протек" в рендеринг или api и т.д. И начинаете вы колхозить ;)
А если вы собираетесь использовать фишки view в связке с ORM... Может быть вам это надо, но я бы не стал ))))
Литература
---
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.
Кроме этого:
Подписывайтесь в Telegram: https://t.me/lets_goto_it
