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

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

A>Надо передать данные по проприетарному протоколу, берем у производителя библиотеку, подключаем, передаем. Как это сделать на бд я тоже представляю, но будет это выглядеть как набор костылей.
Конечно. Не дело СУБД заниматься передачей данных по проприетарным протоколам. Тем более, что это может вносить непредсказуемые задержки во времена исполнения транзакций.

A>Единственный плюс. Но если рассматривать архитектуру всей системы в целом, его даже не стоит принимать во внимание.
Конечно. Отсюда и растут современные заниженные ожидания: железо с начала 2000х ускорилось на порядки, а ентерпрайз системы как прожёвывали заказы по 30 секунд, так и прожёвывают.
Потом оказывается, что общей производительности не хватает, и мы выбиваем бюджет на миграции в NoSQL, который лучше шардится и вообще позволяет делать на 250 машинах то, что при толковом проектировании можно было сделать на одной.

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

A>Вы уж определитесь: "стоит избегать" или "не ограничиваете". Вот есть у вас какой-либо расчет на plsql/tsql. Условно, при закрытии месяца база у вас ложится, потому что этот расчет очень любит процессор. Как будете выходить из положения?
Из моего личного опыта — обычно день-два, потраченных на улучшение "расчёта" окупаются сторицей. То, что там "ложилось", начинает исполняться за 10 секунд. Потому что "ложащийся" расчёт написан на SQL неэффективным образом — множество курсоров, временных таблиц, и прочей наркомании.
"Вытащить" расчёт из базы как правило помогает мало — просто потому, что его производительность упирается в дисковый обмен. (Обычно никто даже не пытается внести в базу вычислительно-интенсивные вещи, типа мандельброта или блокчейна).
Если хранимка прожёвывает гигабайт дисковых данных за полчаса, то не получится её ускорить, заставив сервер приложений тащить этот гигабайт к себе в память.

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

A>Так еще со времен перла. А при чем здесь версия регулярки на базе и на клиенте? Что такое вообще версия регулярного выражения?
Смотрите: вот у меня в запросе использовалась регулярка типа "\(d{3,6}\)". Потом требования поменялись, и стала нужна регулярка типа "\(d{2,11}\)".
Обычно именно такие сценарии пугают в случае наличия логики в сервере — потому что в апп-сервере регулярка уже новая, а в базе осталась старая.
Это и есть "версия регулярки".
Так вот — ничто мне не мешает внутри моего кода сервера приложений вставить что-то типа

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(@SpecificRegex) AND type = 'FS', N'FT')
BEGIN
... -- код по заталкиванию кода функции MyRegex23423521212 в базу
END

Теперь можно писать

select * from mytable where dbo.MyRegex23423521212(data)

В имя функции входит hash от regex string, поэтому мы защищены от конфликтов между разными версиями кода, ожидающими разных регекспов.
Всё это, естественно, спрятано под капот, и в прикладном коде мы пишем запрос на linq2db.

A>>>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
S>>Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.

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

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