Потому что будет одна таблица фактов и 50+ join ов

Сколько этот запрос выполняться будет, с учётом того что и сервера не самые сильные

И?
(не , как будто что-то плохое, ей Коду)

Это сложный вопрос, я тебе не отвечу на него, до тех пор пока не увижу структуру БД и запрос.

нормализация приводит к уменьшению объема хранения, а значит читать обычно придется  меньше. диск - самый медленный компонент ЭВМ. денормализованная схема в виде плоской таблицы будет работать быстрее только если у тебя много памяти и данные с жатом виде, например columnstore index. Если они просто лежат кучей, то из нормализованной таблицы они почти наверняка с 50 джойнами быстрее вылетят чисто за счёт IO при наличии индексов на ключах соединения.

Очень +

И даже там оно для этого уже не используется. ;) И к использованию в принципе не рекомендуется.
Вообще, "встроенное" наследование и все эти "object-relational databases", по-моему, "провалились" на практике.

Я не эксперт в postgresql, но когда прочитал документацию по этой теме, то у меня возникло ощущение, что это очень ненадёжная и нишевая штука, хотя сама идея безусловно хорошая. Я её тогда назвал "диагональным секционированием"

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

Если это нормальный DWH, то у вас должно быть еще куча вещей, которые вы делаете над этими данными. Например в измерениях нужна денормализация дат, извлечение кварталов, месяцев, выходных\рабочих дней, праздников и т.п. Без этого DWH будет плохо себя показывать

Так что это не такая уж большая проблема. один раз запрограммировать извлечение данных.

и написать одну вьюху

Да что в ней "безусловно хорошего"? ;)
Т.е. это вызывает ощущение "ну да, любопытная возможность...".
Но когда доходит до вопроса "как бы это применить на практике?", как-то мысль останавливается.
Хотя, наверное, это off topic.

Ну... я бы применил как раз к моему случаю CMDB, но перф конечно удручает.

Возможно вы правы. Но разбирать по справочникам таблицу в 250+ столбцов, такое себе занятие

а зачем вам эту таблицу дают, если её можно конечному потребителю отдать как есть 😊 простите, если чего не понял

Коллеги у меня вопрос.
Какой уровень изоляции выбирается для запросов на вторичной реплике в AO?
Если перефразировать, то:
Я открываю ssms и делаю select с базы которая была реплицированна с другого сервера. Какие блокировки и на каком уровне я буду накладывать?

А зачем конкретно это в CMDB? И там не в "перф" дело, по идее — это вопрос возможностей и ограничений, скорее всего.

SNAPSHOT вроде по доке. накладываешь SCHEMA_STABILITY

Вот я также думал. Но что будет когда я включу rcsi на первичной реплике?