Не, будут будут. нафиг такая вьюха нужна иначе 😊 материализованная вьюха поддерживается в актуальном состоянии реалтаймом и это вызывает пеналти по перформансу, потому такие вьюхи только для очень важных случаев юзают

Нееее, вьюхи - основа разработки слоя данных. Без них вы будете до опупения переписывать процедуры на любой чих. Правльно написанное решение позволяет абстрагировать логику от формата хранения.

Спасибо всем за ответы) главное на каждый чих не юзать супер-пупер сложную вьюху, когда можно ограничиться только соединением двух  таблицы например.

Создавая вьюху, нужно думать как она будет использоваться и не будет ли крайних случаев. Всё есть яд и всё лекарство.

Ааа это в пг надо refresh делать. Я перепутал. Действительно, сиквел сам все делает.

И дорого за это платит 😊 Да и требования такие, что мне только для самых простых случаев довелось это заюзать.  Вот в том случае, что я описывал выше  (это была система автоматизации администрирования кстати) так была вьюха, в которой юнион делался на таблицы с разными сущностями - экземпляры БД, базы данных, файлы, юзеры, AG и т.п. Типа глобальный каталог сущностей. Вот он нужен был везде. вьюха работала адово медленно, т.к. план включал скан по всем сущностям. Материализовать её нельзя штатно. В итоге я написал вагон триггеров и добился её ручной материализации с обновлением в реальном времени. Получилось здорово, ни разу не пожалел о таком решении.

Крутая система вышла, админили больше 1000 экземпляров и могли в любой момент получить всю аналитику по ним, включая изменения в конфигурации за 6 месяцев

Вагон триггеров, адово медленно... Ни разу не пожалел. Для отслеживания изменений конфигурации есть аудит, есть эвенты например плюс ssis чтобы все это автоматизировать. Нахрена тут материализованные представления вообще не понимаю, ещё и с миллионом триггеров

Адово медленно если постоянно ведется вставка, но речь о каталоге сущностей, они меняются редко. Сбор данных велся воркерами за пределами СУБД. SSIS на это напрягать это оверкилл.

Аудит, ивенты, вообще збс, т.е. собрать текстари со 100500 серверов и парсить? Не выдержит либо система собирающая, либо оверхед на отдающей будет слишком велик. У нас по сути система раз в 15 минут получала снимок данных с серверов, мерджила его, обнаруживала изменения, сохраняла значения параметров в формате key-value.

Эвенты и аудит пишут по факту изменений конфигурации в данном случае. Сами же написали что там редко что-то меняется, соответственно чего там парсить то. Сделали так что все сервера пишут теже эвенты в общую шару, а ssis просто забирает все что там есть и кладет в базу. Где тут хай лоад? Другое дело что я не знаю нюансов вашей задачи, может там какая иная цель была.

сервера далеко друг от друга, общей шары, видимой отовсюду нельзя сделать. Да и нужна безагентская система, чтобы всё через 1433 получать запросом и никак иначе, т.к. иного доступа в ряде случаев нет. Изменений как раз было много, но редко менялся состав объектов. Т.е. баз дофига и больше, новые появляются редко, при этом нужно отслеживать часто меняющиеся параметры. Я пробовал то, что вы описываете,  этого начал, честно говоря, я люблю и знаю эти инструменты, но применение оказалось невозможным.

Ну я говорю что не знаю какая конкретно задача перед вами стояла и тем более ее бекграунд. Просто отметил расхождение, между "адски медленно" и "ни разу не пожалел" )

Спс

#вакансия #ozon #спб
https://spb.hh.ru/vacancy/40096264

вилка: 120-180 net
офис: пл. Ал. Невского

резюме и вопросы:
телеграм: @WizarD51
почта: niproskuryakov@ozon.ru

ребят, а как через запрос к information_schema.columns выбрать имена ВСЕХ таблиц сразу?

и можно ли это вообще

Нужно именно через information_schema.columns? Есть и другие более подходящие представления

ну можно и через .tables