AddxДмитрий МухЗачастую ведь оно как бывает: есть бизнес транзакция в результате выполнения которой данные разлетаются по N таблицам.
А потом, внезапно, собираются из этих же N таблиц + справочники в сложный запрос "в силу сложной бизнес логики".

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

А потом (внезапно) оказывается, что нет. И данные можно рассчитывать в момент записи, и реестров понастроить.
Вот только при каждом изменении их перестраивать надо, а это (внезапно) процесс небыстрый.
И данные нужны чуть сложнее, чем в разрезе одного реестра - операция/остаток.
Впрочем, тут очень сильно зависит от приложения и архитектуры.
Кроме того, всепеределать! не всегда возможно, а хп неплохой уровень абстракции.
Впрочем, я вовсе не принципиальный сторонник бизнес-логики в хп, во многих случаях легко обойтись без них.
Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

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

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.

ОзверинДмитрий Мухпропущено...

Спрашиваю про хранимки, потому что пытаюсь понять, о чём речь.

Аггрегированную выборку, или параметризированную выборку со сложными джоинами можно и в запрос оформить.
А можно и приложение построить так, что аггрегаты будут считаться при записи и данные денормализоваться.
Тогда выборки будут простые и крайне быстрые.

Но это уже вопрос проектирования, а не ORM vs SQL.

И то, что Вы назвали CRUD логикой у вас где, в хранимках?

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

Озверинесли же логика потребуется сложнее, то я сначала накидаю SQL запросы к системе нативные, если они дадут результат - буду думать, куда дальше развивать систему
К примеру логика потребуется сложнее, но запросы при этом простые, то в какую сторону пойдёте?

AddxskyANAОткуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

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

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.

Внезапно = неожиданно для разработчика.
Который думал, что новая технология - это серебряная пуля.
Я рад, что у Вас все получилось. Но это ничего не меняет.
Есть очень разный софт и очень разные задачи.
Можно сделать так
- О появилась новая (ха-ха, некоторые тут про микросервисы в 2018 году узнали) технология, все переводим на нее. Ой, не выходит каменный цветок, плохая технология, плохая.
А можно как одни ребята, которые внедряли какой-то проект (было видео на ютубе, но конечно ссылку не найду)
- Рассморели разные архитектуры - микросервисы, монолит, разные типы хранилищ и поняли, что в этом проекте микросервисы не годятся.
Я бы человека, который сказал бы мне, что микросервисы хороши для любой задачи, на работу бы не взял.
"И тут Остапа понесло"

Регистры - это банальная денормализация. Что в ней, простите, нового?

SergSuperskyANAпропущено...

Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

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

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.а можете в двух словах рассказать что была за задача, какие объемы данных, требования по производительности и т.д.?
АИС ТПС НК "ЮКОС"