Здравствуйте, amironov79, Вы писали:
A>А какая функция сложная? Генерация изображений, документов, анализ данных за продолжительный период?
Два основных класса логики, которые не стоит тащить внутрь СУБД: CPU-bound вычисления и Network-bound обмен с внешним миром.
То есть, скажем, отправлять email изнутри СУБД — плохая идея. Или, скажем, делать фильтрацию изображений.
A>И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?
Минимальное время, которое нужно, чтобы сделать select 1 из MS SQL — 10ms. Сколько бар-кодов можно сгенерировать за 10мс?
A>Гуглам с майкрософтами можно, а другим нельзя?
Именно так.

A>Эээ, какое отношение sql имеет к хранимкам базы? Тем более sql, сгенерированный linq2db.
Ок, продолжаем ликбез. Хранимки бывают двух типов в зависимости от использованного языка: это либо процедурный диалект SQL, либо какой-то язык общего назначения.
Я сейчас говорю о первых.
Linq2db — это пример того, как можно использовать язык высокого уровня для порождения SQL. Это помогает обходить синтаксические ограничения SQL по структурированию кода.
К примеру, на SQL крайне тяжело выразить функцию, которая "к любому датасету с int id добавь join с табличкой accessRights", а на linq2db это делается на раз-два:

public static IQueryable<T> CheckAccess<T>(this IQueryable<T> data, int userId) where T:IIdentifyable<int> => from d in data join ar in accessRights on d.ID equals ar.ObjectID select d where ar.UserID == userId;

Очевидно, что данный подход можно распространить за пределы DML, и получить способ для порождения более сложного SQL кода из кода на Java или C#.

A>Хранимки на языках общего назначения, уже, как бы сказать, не совсем хранимки. В каком контексте будет выполнятся код на "неродном" языке? Насколько я понимаю, для базы эта процедура будет выглядеть как внешний клиент, и на переключении контекста можно много потерять (хотя возможно какие-то оптимизации этого дела и есть).
Нет, для базы эта процедура НЕ будет выглядеть как внешний клиент. И переключение контекста бесконечно дешевле обмена данными с апп.сервером на другой машине.

A>При этом набор языков все-равно ограничен, идет привязка к версии рантайма, который идет с данной версией субд, чтобы настроить разрешения, часто надо идти на поклон к админам. В общем, так себе возможность, но на безрыбье сойдет.
Ну, если так рассуждать, то надо сразу вешаться: в эксплуатации для любого чиха надо идти на поклон к админам. А выбирать версию рантайма не даёт ведущий архитектор — ссылается на какие-то непонятные данные опроса клиентов.
A>А что мандельброт и блокчейн это уже не бизнес логика?
Ну, мне, конечно, сложно себе представить бизнес на основе мандельброта; но я вначале поста дал пояснения по поводу того, как выбирать, какую логику имеет смысл тащить в СУБД, а какую — нет.
A>Техника расширить канал между сервером приложений и сервером субд тоже есть.
Ох-хо-хо. Хотел бы я иметь возможность по щелчку пальцев получать между апп.сервером и СУБД такие каналы, как между SSD и памятью на локальной машине.
A>Я все-равно не понял какую проблему вы решали.
Вижу. Всё же сделайте усилие — перечитайте. Если что-то непонятно — спрашивайте.

A>Компиляция реегулярок тоже не имеет отношения к процедурам в базе. На клиенте базы будет все тоже самое.
Я не понимаю, что вы называете "всё то же самое". С точки зрения кода, который пишется прикладным программистом — да, будет всё то же самое. where zipCodeRegex.IsMatch(userAddress).
Вот только исполняться будет всё совсем по другому: вместо подъёма миллиона строк в память апп.сервера и последующего выполнения client-side filter, всё отработает на стороне СУБД. Уменьшаем сетевой трафик на 90%, примерно вдвое сокращаем время удержания транзакции.

Примерно то же самое, только ещё более заметно, работает для классических хранимок вроде "провести резервирование товара по заказу", которые бегают по складам и ищут оптимальный способ раскидать строчки заказа по партиям товара.
Потому что вытаскивание этого в апп.сервер требует N+1 запросов; это очень долго с точки зрения СУБД. Транзакция, которая могла бы закончиться через 400 миллисекунд, занимает десяток секунд.
Всё это время удерживаются блокировки, мешая параллельным транзакциям завершиться — имеем эффект домино. Люди привыкают считать времена отклика в минуту "нормальными".