спасибо, обязательно выполню его, но пока таблицы не готовы, чтобы делать запросы

А денормализацию лучше делать с помошью вьювов и мат.вьювов.

не совсем понял, в них же прописываются те же джоины и они будут выполняться, как это может помочь со скоростью?

Ну, смотрите. Есть формула факториала. Это по сути число перестановок чисел. Вот её же можно применить к джойнам.
Факториал 6 - это уже 620 вариантов, которые надо перебрать. Так что, в идеале бы вообще три-четыре использовать 3! = 6
4! = 24

Причём к этому надо  прибавлять не только джойны, а ещё и индексы в условиях. Там тоже есть варианты использовать индекс или не использовать. Тоже набегает...

В PG я не знаю лимит. В Oracle стоит перебор 1000 варинатов планов. Какой лучший из них найдёт, такой и будет использоваться. Если лучший не успели перебрать, то не повезло...

Так что, чистая 3НФ нормализация - это на бумаге хорошо. В жизни приходится приходить к компромису, и проводить денормализацию местами...

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

я правильно понимаю, что сложность запроса (если правильно так выражаться) соразмерна факториалу количества джоинов?

Хочу в ближайшее время купить книгу по РСУБД и почитать, но пока есть нужда спроектировать БД прямо сейчас, и приходится задавать глупые вопросы)

хорошо, спасибо

Да. Факториал - это как раз число вариантов соединений, которые придётся перлопатить, и сравнить их стоимость..

понял, спасибо!

подскажите, пожалуйста.
обязательно ли делать create server, чтобы получить данные из соседней базы данных (на том-же сервере)(create foreign table), или есть другой способ?

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

через FDW механизм обязательно, либо можно через dblink

Я хотел бы высказать другое мнение. ;)
Отвечаю Вам, т.к. у меня там есть к Вам вопрос, но обращаюсь и к @Sardorkhuja

> Тут всегда баланс надо искать. Оптимизатор СУБД в реальности может эффективно работать при джойнах менее 5-6 таблиц.

Может быть, это и так в какой-то СУБД, но к PostgreSQL это не относится.

> Если нормализация делает их больше, надо денормализовывать

Нет, не надо. Потому что это, как минимум, преждевременная оптимизация. ;)

> Я думал, нормальные формы — как золотое правило, от которого нельзя отходить

Да, это "золотое правило". Понимаете, как говорил Дейт, нормальные формы — это формализованный здравый смысл (не помню точную цитату). Поэтому, отступая от них, Вы идёте против здравого смысла — в "награду" получая аномалии в данных и проблемы с написанием запросов.

> А денормализацию лучше делать с помошью вьювов и мат.вьювов.

Денормализацию лучше не делать вообще. ;)

> Факториал 6 - это уже 620 вариантов, которые

Любой современный процессор переберёт менее, чем за микросекунду. Мы же не 1980-х, в самом деле...

> В PG я не знаю лимит.

По умолчанию — 8 from items / JOINs. И это немного на современном железе, т.е. можно смело поднимать до 10-12.

> В Oracle стоит перебор 1000 варинатов планов.

Что, серьёзно?! Да это же был бы просто отвратительный оптимизатор!
Послушайте, я просто не могу поверить — у Вас есть ссылка?

> Так что, чистая 3НФ нормализация - это на бумаге хорошо.

Это в принципе хорошо. В жизни — особенно, если данные Вам дороги.

> В жизни приходится приходить к компромису, и проводить денормализацию местами...

Хмм... зависит от того, что именно тут понимается под "денормализацией".

О, опять свидетели денормализации что ли объявились?

Коллеги, привет, а нет ли у кого-нибудь под рукой примеров каких-нибудь обзорных статей или доков по записи в pg данных из топиков кафки?

Из pg в кафку есть debezium, а обратно?

Есть дебезиум

Работает с пг без проблем

спасибо