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

S>Отличный пример. То есть мы делаем round-trip между базой и апп сервером только ради того, чтобы вычислить несложную функцию. Не уверен, что это — архитектурно лучший вариант.

А какая функция сложная? Генерация изображений, документов, анализ данных за продолжительный период? И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?

S>Потом оказывается, что общей производительности не хватает, и мы выбиваем бюджет на миграции в NoSQL, который лучше шардится и вообще позволяет делать на 250 машинах то, что при толковом проектировании можно было сделать на одной.

Гуглам с майкрософтами можно, а другим нельзя?

S>А кто вас заставляет писать на T-SQL? Во-первых, мы можем генерировать SQL, решая проблему структуризации кода. Тот же linq2db и есть пример такого генератора, который умеет порождать высокоэффективный SQL удобным для программиста способом. Во-вторых, все современные РСУБД позволяют писать код хранимок на широком наборе языков общего назначения.

Эээ, какое отношение sql имеет к хранимкам базы? Тем более sql, сгенерированный linq2db.

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

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

А что мандельброт и блокчейн это уже не бизнес логика?

A>>Ну, как бы, не факт. Канал между сервером приложений и сервером субд может быть и быстрее канала между сервером субд и хранилищем данных. Все зависит от конкретных решений.
S>В таком случае у нас есть простой способ: починить канал между сервером и хранилищем. Техника делать быстрые каналы у нас есть.

Техника расширить канал между сервером приложений и сервером субд тоже есть.

A>>А вы приведите сложный. Вы же библиотеку регулярных выражений не на plsql/tsql писали, эта возможность вам любезно предоставлена самим движком субд. Кстати, если бы не было регулярок в движке, как бы выходили из положения?
S>Вот я вам на пальцах объяснил, как добавить поддержку регулярок в СУБД, где их из коробки нету (например, MS SQL).

Я все-равно не понял какую проблему вы решали.

S>Более того — мы потенциально можем строить специализированную версию функции для каждого регулярного выражения, и у нас не будет компиляции строки на каждое обращение к кортежу (как было бы при втаскивании в СУБД единственной функции Regex(string data, string pattern)

Компиляция реегулярок тоже не имеет отношения к процедурам в базе. На клиенте базы будет все тоже самое.