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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сложно сделать выбор (особенно, когда не читал книг), но пока вроде не так много джоинов выходит с 3нф, везет))

сложно сделать выбор (особенно, когда не читал книг), но пока вроде не так много джоинов выходит с 3нф, везет))

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

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

Но сцепления из 8 таблиц со 100 000 записей в результате мгновенно отрабатывали даже в MySQL 5.5 (а вот 2 миллиона в те времена уже тормозили).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А данные из скольки таблиц pgsql может эффективно join-нить?

Не подскажите как поискать best practices для join-ов более 3 таблиц в pgsql?

Привет всем. Можно ли прописать условие в join то есть,  
                 case
                       code_oper = 1
                then join table2  t on a.id = t.id
                else
                         join table2 t on a.code = t.id
                end
?

JOIN всегда выполняется над парой (производных) отношений, поэтому придётся выражать то, что Вам нужно, с учётом этого ограничения.
Например, что-то вроде "JOIN (SELECT ... FROM table1 WHERE first_condition UNION ALL SELECT ... FROM table1 WHERE NOT first_condition) AS two_tables ON two_tables.id = outer_table.something", ну и т.п.

Привет всем. Можно ли прописать условие в join то есть,  
                 case
                       code_oper = 1
                then join table2  t on a.id = t.id
                else
                         join table2 t on a.code = t.id
                end
?

Привет всем. Можно ли прописать условие в join то есть,  
                 case
                       code_oper = 1
                then join table2  t on a.id = t.id
                else
                         join table2 t on a.code = t.id
                end
?

кол-во записей мало влияет, важен общий план и способ доступа к каждой конкретной таблице. если вы там по одной записи из 20 таблиц через IOS дёргаете при горячем кэше — размер таблиц может быть десятки GB

это оконные функции. они работают по результату запроса. почитайте неплохую статью об этом: https://habr.com/ru/post/268983/

Привет. Есть быстрый запрос узнать дату создания таблиц? Нужно поудалять сейчас все старые таблицы, как узнать дату их создания?