Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 83
По моему опыту с Oracle, view как элемент разработки (developer's views) встречается действительно очень редко и польза невелика.
Польза от объекта view всё же есть:
1. Materialized view. Запрос, который выполняется долго, результат меняется мало - такой объект обновляют, скажем, один раз в сутки ночью при малой нагрузке, а клиенты используют днем и часто.
2. Ну и разумеется системные view, когда не дают доступа к исходным таблицам.
Может быть, view вообще были созданы исторически, на заре первых реляционных баз, и они были тогда гораздо более полезными?
По-моему, такое встречается, в разных языках живут реликты до-PCшной эпохи или эпохи процессоров 286.
Например, R - очень хороший язык, но эта "реактивность" по-моему там и нафиг на далась, только усложняет и изучение и отладку. Когда читаешь про зачем и почему реактивность в R -сплошь и рядом одно и то же маловразумительное объяснение мол это делает работу быстрой.
Да, делало наверное лет 20 назад, а сейчас и без реактивности быстро.
извините, приведу цитату из моего любимого МихалЕвграфыча -
"вы считаете, следует ли ссылать литераторов в Сибирь по суду или без суда?
- я, ваши превосходительства, раньше думал что лучше жарить их в Сибирь по суду - крепче будет. А теперь вижу - крепко и без суда!"
Может быть, view вообще были созданы исторически, на заре первых реляционных баз, и они были тогда гораздо более полезными?
Раньше в базе частенько держали бизнес-логику, или хотябы часть ее, тогда и все эти вьюхи, хранимки и даже разграничение доступа использовались намного чаще. Например, в нулевых я видел приложения у которых вообще не было своего управления юзерами, весь контроль, включая rbac был на стороне базы, пользователь вводил логин/пароль, приложение пыталось логиниться в базу с этими введенными данными и пользователь имел тот доступ в системе, который был разграничен для его роли в базе. Вьюхи там использовались вовсю, и напрямую к таблицам доступа ни у кого не было.
Теперь общепринятая практика - вся бизнес-логика на стороне сервера приложений, а база тупо хранилище. Вот и не нужны вьюхи больше. Как и хранимки, rbac и прочее.
Теперь общепринятая практика - вся бизнес-логика на стороне сервера приложений, а база тупо хранилище
Как всегда, обобщение на основе собственного ограниченного опыта.
Очень даже хранят бизнес-логику в stored procedures/functions. И в Oracle, и в Postgres.
"База тупо хранилище" ну может быть в data warehouse приложениях. Работаю 20 лет в Штатах, ни разу не сталкивался с "тупо хранилище". Бизнес логика была на сервере приложений, да, когда работали на формсах. Еще была в шелл-скриптах в фирме которая выпускает автомобильные каталоги. Сейчас вся логика в "хранимках" в фирме которая держит глобальный архив научных публикаций.
Но вьюхи к бизнес-логике опять же непосредственного отношения не имеют.
Курсоры наше все для сложных запросов.
Но вьюхи к бизнес-логике опять же непосредственного отношения не имеют.
Если хочется, то имеют, например пользователь должен видеть только данные своего департмента, вот ему доступ к вьюхам, где данные отфильтрованы по департаменту, а к оригинальным таблицам у него доступа нет.
Про обобщение даже спорить не хочу. Популяризация ОРМ, микросервисов, горизонтального масштабирования, database-agnostic подхода, да банально юнит-тестирования, все это вытесняло бизнес-логику из баз данных.
Вы знаете, вы задели занятную тему. Вот эти вот buzz-words " ОРМ, микросервисы, горизонтальное масштабирование, database-agnostic подход". Здесь на хабре эти словечки кишмя кишмят, (ну и плюс про интервью, джунов, сениоров, выгорание, бла-бла) и даже возникает впечатление у многих что вот она, реальная кипучая буча.
А я по жизни вижу что это все вообще к жизни IT отделов в больших фирмах (звиняйте, в маленьких работать не доводилось) - вообще никакого отношения не имеет. В жизни все как 15-20 лет назад, все по-простому, по-старинке. И весь IT-народ в годах от 40 до 70. И никаких новых серьезных DB-приложений никто не разрабатывает, везде только поддержка или миграция. И кстати, я вижу как высокое руководство тоже заражается всеми этими агентами, ИИ, нам все время спускают какие-то емейлы про семинары, курсы про ИИ, про обсуждения политики...но этот весь хайп он где-то там, он разработчиков вообще не касается, никому это в девеломпенте не нужно, пропускаем все мимо ушей и емейлы автоматом в трэш. И здесь вот на хабре какой-то безумный хайп, а жизнь-то...она проходит рядом и параллельно и этот хайп в ней как те сократовские тени на стене пещеры. Помните в фильме про Молчаливого Боба - "вот это пульс, вот это - палец, и он далеко от пульса!". Вот это - жизнь IT отдела, вот это - бурные дискуссии на хабре, и они далеки от жизни!"
Моё IMHO, спорить не стану.
ЗЫ примерчик из жизни и болтовни: во всех емейлах мол, think out of the box, innovation, frontiers...меня попросили сделать простой фронт-енд для простейшего DB-приложения, 5 табличек, исключительно для внутреннего пользования, на десяток юзеров максимум. Сделать "на чём-нибудь на ваше усмотрение". Я оканчивал пажеский корпус (биофак МГУ) и ваших веб-фреймворков не обучен, пошарился в сети и слепил миленький фронт-енд..на R, там есть библиотечка Shiny, все ГУИ-виджеты, готовые гриды, только распихать по клеткам на странице. Маленькая программа получилась, всего два текстовых файла, закидываешь по FTP на амазоновский микро-образ люникса и все летает. Сделал, продеплоил, презентовал, молчат. Потом главный менеджер IT - мол, это сложно, так никто не делает и у нас нет ресурсов которые будут поддерживать программу на таком странном языке. Через пол-года дали нам супер-пупер питониста, он уже почти год лепит нам чудище обло на Flask, там у него все самое модное - и Docker, и Jenkins, сам чёрт ногу сломит. Причем он временный, слепит это самое, уйдет и что - из наших айтишников никто и питона-то не знает, а уж Flask тем более, и Docker, Jenkins - вообще китайский язык.
Думайте, говорят, out of the box. Инновации, говорят. Учите новое, расширяйте квалификацию, говорят.
П<>болы, везде п<>болы.
Вы знаете, вы задели занятную тему. Вот эти вот buzz-words
...
Причем он временный, слепит это самое, уйдет и что - из наших айтишников никто и питона-то не знает, а Docker, Jenkins - вообще китайский язык.
Докер уж лет 10 как продакшн-реди, лет 6 как стандарт де-факто. Дженкинсу в этом году 15 лет. Когда работал с ним 7 лет назад, то он уже казался лютым олдскулом. При этом нишевый язык R для вас норм. А я о нём знаю только в контексте биотеха, например.
В целом-то совет думать out of the box не такой и дурной.
Я лично ненавижу слово "стандарт" в обсуждении разработки. Прям кюшать не могу. ВСЕГДА это вот "у нас есть стандарт" используется как "аргумент" для оправдания бессмысленных, неправильных и волюнтаристских практик к которым принуждают разработчика. "У нас agile стандарт"! "У нас docker стандарт" и прочий бред, простите мне мой клатчский.
Муму-папа говорил: "не то хорошо, что хорошо, а что к чему идет".
Подумайте об этом, Муми-папа плохого не скажет.
Но вы я вижу даже не поняли что "совет думать out of the box" - это пример корпоративного лицемерия и демагогии. Судя по тому, что для вас язык R - "нишевый" ...да что там.
Я лично ненавижу слово "стандарт" в обсуждении разработки
А я вот грешен. Люблю стандарты. Везде. Мне очень нравится, что USB 3.0 в Китае и во Франции это одно и то же. Или болт M6x20 в Индонезии не отличается от такого же болта в Финляндии. И в разработке тоже классно, что приходишь на новый проект и начинаешь сразу работать, а не изучать местные велосипеды.
Судя по тому, что для вас язык R - "нишевый" ...да что там.
Судя по тому, что для вас докер баззворд...
И вас не смущает ситуация когда менеджер IT комады из 4х человек на возражение нового разработчика что нельзя хардкодить мастер-пароль в коде приложения заявляет: у нашей команды есть стандарты и мы их не обсуждаем. Я вот про эти "стандарты". Любое ничтожество на ступень выше корзинки для бумаг использует "стандарты" чтобы затыкать "сильно умных".
мастер пароль в хардкод мелочи. Хуже когда вместо сборки бизнес-логики в один кучерявый цикл, слышишь что у нас стандарт и 1 действие на завернуть в одну функцию и .. требование размазать коммит по функциям с циклом внутри. Производительность падает /N но в ответ слышишь "у нас крутой сервер, а стандарт нарушать нельзя, если заткнется попросим руководство купить новую стойку".
Не передергивайте. Стандарт в железе это не просто хорошо, а придумано давным давно. ГОСТом зовется. А вот "стандарт в программировании" это совсем иное. Ещё худо-бедно можно принять некий "стандарт" в девопсе, ну .. "не ругайте пианиста от играет как умеет", а вот "стандарт" в бизнес-логике - это дурь, полностью соглашусь с вашим оппонентом.
Передергиваю тут не я. Мой тезис был про том, что докер есть стандарт де-факто и уж точно не баззворд в 2026 году. Где докер и где бизнес-логика? Мне на это отвечают что-то про ненависть к стандартам, волюнтаризм, какого-то менеджера, какой-то хардкод. Про Фому и про Ерёму, как говорится.
стандарты разные бывают, и в бизнес логике тоже. Другой вопрос - называть стандартами то, что ими не является - это дурь. Но стандарты есть во всем - и вы их используете, просто можете даже не догадываться об этом.
"Стандарт" означает, что им не придётся ломать голову над требованиями к вакансии человека, которого они наймут поддерживать это приложение.
Звучит как крик души человека, которому бездушный CI/CD завернул пулл-реквест из-за неправильных отступов)
Стандарт нужен просто для того, чтобы новый разраб вкатился в проект за неделю, а не реверс-инжинирил твои уникальные паттерны полгода
Стандарт нужен для того чтобы при наличии 10 проектов и 5 разрабов переключение их между проектами было легко и непринужденно. Когда во всех проектах всё находится по стандартным местам, называется тоже стандартизованно и выполняет атомарные операции, то любого разработчика можно привлечь на любой проект. Для бизнеса очень плохо когда все как хотят так и пишут. Разрабы узкоспециализированы по проектам и свои компетенции и знания кодовой базы держать в тайне в своей голове. Почему кирпичи делают прямо и перпендикулярно и более менее одинакового размера - чтобы когда строится дом не нужно было каждый раз решать а что в этот кирпич хотел вложить его создатель.
А я по жизни вижу что это все вообще к жизни IT отделов в больших фирмах (звиняйте, в маленьких работать не доводилось) - вообще никакого отношения не имеет.
А IT отделы в фирмах, доходы которых напрямую не зависят от их програмных (ну либо програмно-аппаратных) продуктов, в целом мало отношения имеют к тому, что понимают под IT.
т.е. IT-отдел, скажем, в Газпроме или Сбере - это не IT, так, шарага
А вот IT-отдел, например, в Люксофте - это ого-го.
Очаровательно.
ИТ-отдел в Сбере, иначе известный как Сбертех это, в каком-то смысле, и есть Сбер сегодня, у Сбера ИТ сейчас (да и практически у любого банка) - основа деятельности. Про Газпром не знаю.
Не совсем корректные примеры, у сбера ИТ направление развито и является основой деятельности, как и у любого другого банка - экосистема, все дела. Газпром отдельный прикол, с их-то количеством дочерних компаний. Но вот скажем ИТ отдел на каком-нибудь заводе (если не брать мастодонтов) и ИТ отдел сбера это разные вещи.
Ну это такого суперспеца вам дали, если он полгода лепит фронт к 5 табличкам.
Я работал на заре карьеры в компании, которая не имела никакого отношения к ИТ и мы были прислугой (хотя относились к нам хорошо). Очень типичная картина, кто на чем привык - на том и пишет, лет по 10-15 на одном и том же, что-то новое попробовать - пожалуйста, если у тебя зудит, делай что хочешь. Если не хочешь - не пробуй, у нас проверенного FoxPro (олды знают) сколько угодно. Но это не типичная для ИТ-отрасли картина.
вы делаете вывод что он плохой специалист?
ну, вы рассуждаете не лучше.
Он явно знающий спец, но у него нет мотивации и он по сути работает 15 минут раз в неделю, как раз перед нашим еженедельным созвоном в MS Teams.
Какого суперспеца не посади, если он бесконтрольно работает на почасовке или без сроков, он когда-нибудь потом будет вашими проблемами заниматься.
Кстати, как мне кажется, если что-то пишется в рамках деятельности компании, всегда есть типовой интсрументарий. Если же решили делать что-то нетипичное, там в первый раз делается кто во что горазд. А потом уже делают с оглядкой на этот опыт.
Отдельный прикол кстати когда все используют комбайн, но по-разному. Вот с qt всегда прикольно. Один использует чистые QWidget, другой QWidget + QSS, третий сидит на формочках, четвёртый на QML. Отдельные уникумы вообще переопределяют paintEvent или QGraphicsView, добавляют биндинги на другие языки или используют WebEngine.
20 лет назад мобилки были так себе. Щас любой веб-сайт должен уметь работать во всех девайсах и браузерах. Непонятно как только с помощью "поддержки" сие осуществить.
Я работал во многих конторах и вподавляющем большинстве там были и докеры и дженкинсы. Ваш случай нерепрезентативен.
Но вообще пост похож на какой-то троллинг если честно
Насколько мне видится, написать фронт на нишевом R это как раз-таки out of the box решение. А вот использовать стандартные инструменты это как раз-таки правильный путь. Думать out of the box нужно только в том случае если in the box решение нас не устраивает.
Приведу пример. Я вообще c/c++ разработчик, иногда пишу на питоне, иногда использую матлаб. И вот как-то надо было накалякать приложение на Android. Что я сделал? Правильно, взял стандартный вариант - kotlin + jetpack compose. Единственная вольность которую себе позволил - для работы с serial написал свою реализацию на kotlin.
Дело не том, инновация или нет, баззворд или нет. Дело в целесообразности. Если достаточно запилить монолит, не вопрос, делаем. Если мы прикинули и поняли что монолит не подойдёт, окей, микросервисы. Если нам норм держать логику в базе, окей, нет - выносим логику, если надо ОРМ используем. Достаточно наколеночного решения, хозяин барин.
А по поводу питониста
Анекдот
Молодой адвокат прибегает к своему отцу — старому адвокату и радостно говорит: "Отец! Я выиграл дело, которое ты вел 20 лет!". Отец ему отвечает: "Дурак ты, сынок! Благодаря этому делу я вас 20 лет кормил..."
Не, тут по другому - единственная система на которой имеет смысл иметь бизнес логику в базе - это Oracle. Там все сделано для людей. Даже очень похожий постгрес уже гораздо менее удобен.
Указали, что "теперь общепринятая практика" для новой разработки, поддержка того, что программировалось 10-20 лет назад - это как всегда другая история.
Молодые программисты в большинстве своем в SQL не лезут вообще, пользуются ORM.
Немного не так. Как в статье написано, materialized view обновляется в постгресе без инкремента, поэтому следующим шагом будет создание таблицы с инкрементным обновлением хранимкой по расписанию в pg_cron, а view исчезнет.
Многие конторы и их рахработчики (по крайней мере лет 5 назад) были яростно против хранимок вообще как факта. Не в курсе как сию, отошел от скуля.
Да я сам всё перетянул в даги airflow - просто чтобы всё на виду было. Это вопрос организационной, а не технической сложности.
Раньше в базе частенько держали бизнес-логик
Был опыт работы в одной команде, которой надо было пилить свои фичи взаимодействуя с проприетарным ПО, у которого отсутствовало API, но были свои хранимки в БД. Вот через них мы и делали интеграцию.
Отладкой было не приятно заниматься.
Самый сок происходил после обновления софта.
Теперь общепринятая практика - вся бизнес-логика на стороне сервера приложений, а база тупо хранилище. Вот и не нужны вьюхи больше. Как и хранимки, rbac и прочее.
Это правило работает только для типичных крудов и микросервисов на полтора эндпоинта. Загляни в любой живой корпоративный DWH, там этих вьюх столько, что без поллитры не разберешься
По моему опыту с Oracle, view как элемент разработки (developer's views) встречается действительно очень редко и польза невелика.
Сам Оракл с вами не согласится, ибо вспоминаем про встроенные вьюхи user/dba/all_*
Сам Великий и Ужасный Оракл - имеет главной мотивацией не развитие технологии и удобство разработчиков и пользователей, а новые яхты Ларри. Тоже мне авторитет. Был, да весь вышел. Формсы убили, JDeveloper не взлетел, APEX у них теперь "приложение", а ведь задумывался то как HTML DB.
Сам Великий и Ужасный Оракл - имеет главной мотивацией не развитие технологии и удобство разработчиков и пользователей, а новые яхты Ларри.
Это можно сказать про любую коммерческую компанию
JDeveloper не взлетел
Ну он откровенно был убог, особенно в сравнении с PL/SQL Developer и Toad. Плюс ещё и бесплатный продукт, которых жрёт бюджет. Поэтому на него в 2013м положили огромный болт. Не может же Ларри несколько лет подряд ходить на одной и той же яхте?
а я уже писал что не отрицаю пользу материализованых и системных вьюх. Вы не читали?
Если в R под реактивностью имеются в виду ленивые вычисления, то польза от них очевидна: без них не работало бы nonstandard evaluation, на котором основаны dplyr, data.table и многое другое. Всё это работает так удобно благодаря тому, что аргументы функции не вычисляют сразу, и с ними можно работать, как с выражениями
На своей практике встречал подмена данных через view. Сначала у нас есть старая таблица с данными и view на нее, потом мы создаём вторую таблицу и после ее заполнения меняем view уже на нее, тем самым получаем новые данные без задержки в подмене
С одной стороны сложно согласиться с ненужностью представлений (view). В проектах с ORM действительно нет view, либо их единицы.
С другой стороны применение view довольно простое: для ограничения доступа (создали view, добавили фильтр и выдали права пользователю, можно даже менять данные в колонках); хранение запросов, чтобы не дублировать код в десятках местах; просто спрятать большой запрос во view (например, гигантский merge с сотней колонок, часть с select уходит во view).
Современные СУБД довольно сильно оптимизируются запросы, так что проблема производительности обычно не стоит, стоит выдача гранулярных прав доступа и поддержка кода: https://javarush.com/groups/posts/423-kljevihe-optimizacii-sql-ne-zavisjajshie-ot-stoimostnoy-modeli-chastjh-5-
Небольшой оффтоа. А вы клодом писали эту статью или кем, если не секрет? Просто он так качественно выдаёт тексты в таких формулировках, которые кажутся умными, но понять этот текст намного сложнее, чем тут написанный человеком или даже кодексом. Если вообще он имеет смысл, потому что я устал бороться с клодом на тему его некомпетентности, вранья и скрытия косяков. И его стиль мне узнается теперь часто. Судя по негативу в зарубежных соцсетях, я уже не один такой параноик.
ИИшка тут точно потопталась. Очень знакомый паттерн, когда в тебя как будто выстрелили картечью из терминов вперемешку с обычными словами в пропорции 1:1. Читаешь, читаешь, потом мысль "А что сказать-то хотел?".
Текст написан мною вручную. Все замеры берутся со стенда github.com/alex-frolov/mysql-postgresql-view-test, и запускается одной командой. Если есть конкретные технические вопросы по цифрам или планам - с удовольствием разберу.
А что на счёт клика? можно такой же замер с кликом?
Стенд открыт на github.com/alex-frolov/mysql-postgresql-view-test, там docker compose up && make bench. CLICK-подобные ворклоады прогоняются так же, дописываешь свой SQL в bench/queries.sql и запускаешь. Если соберёшь интересные цифры, присылай PR, с удовольствием приму, посмотрю. Можно и здесь обсудить.
View позволяют разделить физическое хранение данных от их использования. Через view создаем интерфейс доступа к данным.В процессе разработки и эксплуатации может меняться физическая схема, а view позволяют поддерживать неизменный интерфейс. Кроме того во view можно заложить сложный запрос, который пишут те люди, которые знают физическую схему базы данных, а прикладные программисты выдвигают требования в каком виде им требуются данные. По сути view позволяют создать "витрину данных" для прикладных задач. То же самое касается и функций. Так что функции и представления полезны и позволяют организовать технологию разработки и эксплуатации разделяя, степень ответственности и компетенции.
прямо слово-в-слово из рекламной брошюры 40-летней давности.
шутки шутками, а у меня большой DWH с кучей команд в одной базе. И для разграничения доступа (и ответственности) все ходят друг к другу через вью-интерфейсы. Это действительно удобно и кучу раз нас выручало, когда схема за вью менялась
У нас это называется "витринами". Я последние лет пять только и делают что леплю вью для различных подразделений кампании.
ну витрины - это обычно то, что отдается бизнес-пользователям. Перед витринами у нас тоже стоят вью в роли интерфейсов)
Согласен, в DWH, много-командных базах и при миграциях view, как контракт - интерфейса незаменимы. В статье это в итогах: "переиспользуемый фильтр и стабильный контракт чтения", "разделение прав", "мягкая миграция", "legacy, который проще обернуть". Мой кейс это OLTP highload, там агрегаты, часто дешевле выносить в сводные таблицы с инкрементальным обновлением.
«Древние» знали толк в оптимизации. Их еще не развратили современными мощностями, которые покрывают нежелание программистов писать код оптимально )
Точно. В статье это "переиспользуемый фильтр и стабильный контракт чтения" + «"legacy, который проще обернуть". Для OLAP/DWH — основной паттерн.
Например юзер может быть удален, заморожен, заблокирован, а я хочу работать только с живыми юзерами. Создаем view и работаем только с этим view.
create or replace view active_users as select * from users where status_id is null;
Меньше рисков потерять условие, меньше сами запросы, меньше дублирования логики.
Разделение ответственности. VIEW - бизнес логика, TABLE - хранение.
Сравните CREATE TABLE statement и CREATE VIEW.
CREATE TABLE - это партиции, tablespaces, компрессия и прочие ДВА штучки.
Для представления -
Можно пересоздавать(REPLACE), очень удобно в скриптах
поддерживаются EDITIONING, без версий тестирование - боль.
WITH READ ONLY, WITH CHECK OPTION, BEQUEATH наконец.
Я ответил честно: в живых проектах они мне почти не попадались; для агрегатов надёжнее держать отдельную таблицу; а сами представления — вещь настолько нишевая, что за карьеру пригождались считанные разы. Разделение прав, долгие миграции, совместимость со старым ПО — вот и весь список. Ответ приняли прохладно.
мне кажется я понимаю почему они приняли ответ прохладно
Представления прежде всего нужны когда у тебя есть один сложный sql запрос, который используется во многих местах. Ты создаешь представление и используешь его. Когда тебе надо внести в него изменение, ты вносишь только в одном месте изменение, а не начинаешь судорожно искать где у тебя используется этот sql.
Я думаю все иначе. Подозреваю, что люди вроде автора работают через ORM. Когда ты перманентно находишься в application layer, то испытываешь.. проф искажение: не вижу, чтобы использовали в моей кампании - нигде не используют. На деле такие правила чаще всего существуют по присинам как в анекдоте "тут так заведено".
Иногда требуются какие-нибудь хитрожопые SELECT'ы с фильтрами к результату соединения пары десятков таблиц. Писать такие соединения "каждый раз" напрягает. Проще завести VIEW (обычный, не материализованный), а потом к нему во WHERE добавлять только фильтры. Типа SELECT * FROM MyMegaView WHERE <динамически собираемый фильтр>
Тут нужно начать с CAST(o.created_at AS DATE) AS day и group by по ней же.
Вот я, как DBA, дал бы разрабу по башке. Потому что это азы SQL. Да, можно достроить потом индекс по вычисляемому полю, но может сразу делать хорошо, плохо само получиться? Вьюхи вообще прозрачны для планировщика (кроме материализованных или имеющих триггеры), это просто подстановка текста, не более того - посмотрите текст который идет на компиляцию.
Так функциональные индексы для того и придумали, чтобы спасать кривые схемы без даун тайма. Навесил индекс на выражение и пошел спать, зачем трагедию из этого устраивать)
Функциональный индекс на ((created_at)::date) это правильный фикс. В статье показано, почему без него планировщик не может использовать индекс (merchant_id, created_at), view выставляет наружу day как выражение, а не колонку. Функциональный индекс решает, но требует DDL и понимания, что view «молча» ломает саргабельность, именно этот момент показателен, без вникания и проверок можно попасть на ровном месте.
По моему у ТС какие-то тараканы в голове. Шутки на собеседовании это просто средство разрядки атмосферы. В практике ТС они видимо не используются, так же как и вью.
Насколько я понял, у ТС базы примитивной структуры и примитивные запросы в них, со сложными предметными областями он не сталкивался. У многих комментаторов выше, по-видимому, аналогично. Совершенно естественно, что VIEW им не особо полезны.
Представления полезны как прослойка между клиентской частью и таблицами с данными.
Клиентская часть не имеет прямого доступа к данным, не знает структуру БД, что полезно для безопасности, ну и для разработки полезно то что внутри структуру таблиц можно менять, а клиенту в представлении показывать всё неизменно по структуре и клиентскую часть не надо будет изменять, ну или делать это значительно реже.
Хотя статья написано или пропущена через нейронку на 100%, комментаторы не отстают. Либо выдают шаблонные ответы, либо отвечают не по сути. В статье приведены замеры, а в ответ: ну так ведь удобней, ну у автора примитивные данные, наверно. Один про фому, другие про ерёму.
Ми когда-то view кодом генерили (очень давно), это были своего рода ui настройки. Самое первое предназначение было - делать запросы короче (текст запроса).
Поднять стенд с двумя базами и нагенерить миллионы строк чисто из-за уязвленного эго на собесе прям база. Сам так делал, когда доказывал лиду, что его новая архитектура не взлетит)
Мы вьюхи применяем если надо в ходе интеграции предоставить доступ к чётко оговорённым данным. Исполнитель на бэке может поленится и забрать из таблиц все столбцы. Вьюха же не отдаёт ничего лишнего.
кмк вьюхи это прежде всего следствие концепта что база владеет моделью и предоставляет интерфейс в виде не только в виде запросов но и вьюх и хранимок и функций. Раньше (90е - 00е) было много проектов в такой парадигме, но пришел ORM и микросервисы. Если вы используете ORM или у вас сложная разделенная модель и база уже не владеет моделью вьюхи вам особой пользы и не принесут.
Статья полезнее как учебник «не рассуждай о SQL абстрактно — смотри план», чем как статья «VIEW плохи». Иронично, но эксперимент скорее реабилитирует VIEW: почти во всех местах, где происходит что‑то странное, виноват не объект VIEW, а форма relational expression, индексы или границы оптимизации.
у PostgreSQL work_mem дефолтные 4 МБ
Очень зря. Постгрес надо настраивать под доступные ресурсы, хотя бы базово.
View просто еще один уровень абстракции поверх данных. Вы можете предоставлять view как удобный контракт получения данных, такой же как REST или RPC. Предоставили view, сказали сервису строку подключения и готово. Звучит архаично, но работать будет.
Спасибо за замеры и за план запроса — обычно про вью спорят на уровне ощущений, без цифр. Интересно было бы увидеть то же самое на объёме побольше и с индексом по created_at.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Меня подняли на смех за ответ про VIEW. Я поднял MySQL 8.4 и PostgreSQL 17 и померил