Тут в базе разбирался и увидел, по мне избыточность.

есть таблицы

А > B > C > D

корневой объект А, а дальше идет отношение 1-М.
Так вот в таблице D есть столбцы Id для всех таблиц A-D
Я конечно идею понял, чтобы не делать 3 джойна, а сразу одним селектом вытащить всё из D, когда работаем с D.
Но это же избыточность явная или в высоконагруженных приложениях так делают для производительности?

Здравствуйте, peer, Вы писали:

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

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, peer, Вы писали:

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


удаление есть и не сказать что летает всё. основные тормоза идут как раз на вставке. там коненчно вставляется за раз по 200К строк в D

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

Здравствуйте, peer, Вы писали:

P>Я конечно идею понял, чтобы не делать 3 джойна, а сразу одним селектом вытащить всё из D, когда работаем с D.
P>Но это же избыточность явная или в высоконагруженных приложениях так делают для производительности?

Денормализация данных

Когда диски были маленькими, а деревья — большими — все дрочили на минимизацию объёма хранимых данных. Сейчас на объёмы всем уже насрать. Если не ошибаюсь, тот же яндекс выпустил в свет хранилище, в котором данные никогда не удаляются в принципе. Сейчас дрочь идёт на скорость, а для скорости денормализованные данные гораздо полезнее нормализованных

У меня в конторе в одной ещё в нулевых отчеты по несколько суток создавались на мс сиквеле, да и многое другое было не слишком быстро. И всё из-за нормализации. Но тогда нельзя было хранить денормализованное, тогда стоимости ёмкостей не позволяли

Здравствуйте, peer, Вы писали:

P>... так делают для производительности?

Или для https://en.m.wikipedia.org/wiki/Many-to-many_(data_model)

Здравствуйте, peer, Вы писали:
P>Но это же избыточность явная или в высоконагруженных приложениях так делают для производительности?
Для производительности.
Того же самого можно добиться, построив indexed view DOpt as

select d*, c.id, b.id, b.aId 
from d 
inner join c on c.id = d.cId
inner join b on b.id = c.bId

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

S>И при прочих равных я бы предпочёл именно такой подход — потому, что эту вьюху можно убить (или заменить на неиндексированную) для ускорения серии балк-вставок, а потом пересоздать (сделать индексированной), когда запросы на чтение начнут доминировать.

При bulk вставке можно и на таблице D индексы отключить и избыточные колонки NUL`ами заполнить. А по окончании вставки заполнить актуальными значениями и индексы построить.
Имеет ли indexed view в таком случае преимущество применительно к сценарию bulk-вставки?

Здравствуйте, m2user, Вы писали:
M>При bulk вставке можно и на таблице D индексы отключить и избыточные колонки NUL`ами заполнить. А по окончании вставки заполнить актуальными значениями и индексы построить.
M>Имеет ли indexed view в таком случае преимущество применительно к сценарию bulk-вставки?
Имеет, хоть и не категорическое — тут идёт работа только с метаданными.
Заполнение колонок NULL означает, что в течение какого-то времени запросы к D, написанные в надежде на колонки, будут выдавать ерунду.

Архитектура поверх view позволяет балансировать эффективность вставок/поисков, не трогая остальные запросы.
То есть схема остаётся всегда одна и та же, но в зависимости от наших предпочтений какие-то из колонок вычисляются, а какие-то — хранятся.
Частный случай такого тюнинга — как раз серия балк-вставок. "Сейчас нам важнее быстро вставлять, давайте передвинем ручку в сторону вычисления на ходу".

Здравствуйте, peer, Вы писали:

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

зависит от да, баланс crud/query играет
но по умолчанию я бы делал, убрал бы точечно где мешает