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

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

A>Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?
В локальности.

A>Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.
Ну и что?
A>И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?
Как раз я предлагаю не ограничивать. Это вы хотите ограничиться логикой в app server.
A>А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?
В зависимости от конкретной задачи. Тут универсальными мантрами не отделаешься.

S>>А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений.
S>>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).
A>Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.
За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
S>>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.
A>Здесь вообще не понял про что речь. Статическая компиляция регулярки?
Конечно. Вы же знали, что регулярку можно скомпилировать, а не интерпретировать?
A>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.