Всем привет! Сейчас пытаюсь спроектировать бд по трем первым нормальным

формам (занимаюсь этим впервые), и стоит вопрос. Если делать по НФ, таблицы получаются большими, и их выходит много. Но мне при запросах с бэкенда нужно разом доставать значения с большого количества таблиц.

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

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

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

Просто любопытство, сколько джоинов будет в одном запросе +- если вы сделаете 3нф?

я пока не все продумал и создал, но предполагаю, что будет как раз примерно 5

А теперь правильный ответ: на поставленный вопрос сможет ответить только EXPLAIN (ANALYZE, BUFFERS)

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

Ну, смотрите. Есть формула факториала. Это по сути число перестановок чисел. Вот её же можно применить к джойнам. Факториал 6 - это уже 620 вариантов, которые надо перебрать. Так что, в идеале бы вообще три-четыре использовать 3! = 6 4! = 24 Причём к этому надо прибавлять не только джойны, а ещё и индексы в условиях. Там тоже есть варианты использовать индекс или не использовать. Тоже набегает... В PG я не знаю лимит. В Oracle стоит перебор 1000 варинатов планов. Какой лучший из них найдёт, такой и будет использоваться. Если лучший не успели перебрать, то не повезло... Так что, чистая 3НФ нормализация - это на бумаге хорошо. В жизни приходится приходить к компромису, и проводить денормализацию местами...

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

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

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

Я хотел бы высказать другое мнение. ;) Отвечаю Вам, т.к. у меня там есть к Вам вопрос, но обращаюсь и к @Sardorkhuja > Тут всегда баланс надо искать. Оптимизатор СУБД в реальности может эффективно работать при джойнах менее 5-6 таблиц. Может быть, это и так в какой-то СУБД, но к PostgreSQL это не относится. > Если нормализация делает их больше, надо денормализовывать Нет, не надо. Потому что это, как минимум, преждевременная оптимизация. ;) > Я думал, нормальные формы — как золотое правило, от которого нельзя отходить Да, это "золотое правило". Понимаете, как говорил Дейт, нормальные формы — это формализованный здравый смысл (не помню точную цитату). Поэтому, отступая от них, Вы идёте против здравого смысла — в "награду" получая аномалии в данных и проблемы с написанием запросов. > А денормализацию лучше делать с помошью вьювов и мат.вьювов. Денормализацию лучше не делать вообще. ;) > Факториал 6 - это уже 620 вариантов, которые Любой современный процессор переберёт менее, чем за микросекунду. Мы же не 1980-х, в самом деле... > В PG я не знаю лимит. По умолчанию — 8 from items / JOINs. И это немного на современном железе, т.е. можно смело поднимать до 10-12. > В Oracle стоит перебор 1000 варинатов планов. Что, серьёзно?! Да это же был бы просто отвратительный оптимизатор! Послушайте, я просто не могу поверить — у Вас есть ссылка? > Так что, чистая 3НФ нормализация - это на бумаге хорошо. Это в принципе хорошо. В жизни — особенно, если данные Вам дороги. > В жизни приходится приходить к компромису, и проводить денормализацию местами... Хмм... зависит от того, что именно тут понимается под "денормализацией".

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

так основная цель не оптимизация джойнов, а грамотное управление данными

А тут выбор-то простой — можно быстро "портить" данные (если игнорировать нормализацию), или ещё быстрее их нормально обрабатывать (если нет). ;) Шутки шутками, но не так уж редко "денормализация" и т.п. заканчивается тем, что в плане производительности (по результатам измерений), что всё становится ещё хуже... а иногда и данные начинают искажаться. Т.е. к этому нужно очень аккуратно подходить, а не в стиле — "увидел 5 JOIN-ов, в [рефлекторном] ужасе побежал денормализовывать". ;)

>>Тут всегда баланс надо искать. Оптимизатор СУБД в реальности может эффективно работать при джойнах менее 5-6 таблиц. >Может быть, это и так в какой-то СУБД, но к PostgreSQL это не относится. А данные из скольки таблиц pgsql может эффективно join-нить? Не подскажите как поискать best practices для join-ов более 3 таблиц в pgsql?

> А данные из скольки таблиц pgsql может эффективно join-нить? Потенциально — из сколько угодно. Речь-то о времени планирования была. > Не подскажите как поискать best practices для join-ов более 3 таблиц в pgsql? Я не понимаю вопроса. Просто пишете запросы, зачем тут "best practices"?