Дякую, додав згадку про extended stored procedures

Так, дійсно, про них зовсім забув. Вибачаюсь!

Т.е. у вас с сервера БД идут исходящие запросы куда-либо во внешний мир? Интересно.

Ага! Веб-реквести.

А почему это не могла сделать первая?

Та може. Це я щоб створити інтригу))
А насправді, щоб відділити логіку, яка ходить у зовнішній світ, від логіки, яка живе у базі

ну, DB-инженер то точно ж не уволится.

Та да))
Або його наступник точно знатиме, що All You Need Is LoveDatabase.

Ну, от, наприклад, придумав таку жартівливу історію.

Компанія розробляє і підтримує якусь фінансову систему. На початок кожного дня потрібні курси валют. Задача тривіальна, DB інженер написав скрипт на PowerShell або SQL+Python, вставив його в SQL Server Agent або інший скедулер в СКБД, запускається в 09:00, з API Нацбанку бере курси валют, вставляє в таблицю, робить валідацію. Потрібні якісь зміни в коді — просто відредагував SQL чи PowerShell скрипт. В разі фейлу є лог з помилками. В 10:00 інша джоба перевіряє, чи є дані і чи валідні вони. Налаштована нотифікація від обох джобів. Тобто весь процес від отримання даних із зовнішнього джерела до зберігання в базі знаходиться в одному місці і в зоні відповідальності однієї людини (умовно) — DB інженера.
Одного дня PM каже: «Робимо мухи окремо, котлети окремо. База даних у нас тільки для зберігання даних. Як сказав Роберт Мартін, база даних — це лише дверна ручка в архітектурі будинку». Ок, зробили окремий сервіс на окремому сервері або додали цей функціонал в існуючий. Все добре. Підтримує все це адмін Вася.

І якось в чаті з адмінами:

10:01.
— Привіт! Васю, немає курсів валют!
— Ой, та ми вчора міняли паролі до системних екаунтів, зараз подивлюсь!
Іншого дня
10:01.
— Привіт! Васю, немає курсів валют!
— Ой, та ми вчора задеплоїли нову версію, зараз подивлюсь!
Іншого дня
10:01.
— Привіт! Васю, немає курсів валют!
— Ой, та ми вчора переїхали на новий сервер, зараз подивлюсь!
Іншого дня
10:01.
— Привіт! Васю, немає курсів валют!
— Ой, та там у них помінявся формат респонса, зараз буду шукати розробника Колю, який буде шукати код, написаний розробником Сашею, який звільнився рік тому. Коля внесе зміни, збілдить проект і задеплоїть!
Іншого дня
10:01.
— Привіт! Васю, немає курсів валют!
— Ой, а Вася звільнився, це адмін Діма, мені потрібно кілька днів, щоб розібратись, як тут у Васі все було налаштовано!
Думаю, що попередня структура без ланки «адмін Вася» була краща.

Отут також добре описано, чому база даних — не дверна ручка
medium.com/...​-is-a-detail-eda7424e8ce2

А щодо Роберта Мартіна — так з ним багато хто не згоден
journal.optivem.com/...​-database-is-not-a-detail

Чи оце воно?

і шо ?

Щось я не бачу тут питання

колись вкладався у Silverlight і VB.NET і шо ?
апеляція до авторитету — слабкий аргумент

Якщо я щось, що роблять інші люди, не розумію, то виникає 2 версії: або я чогось не знаю, або вони. Наприклад, йду по вулиці, робітники риють канаву. По моїх даних, тут ніяких комунікацій не повинно бути. Тобто, або в мене неповні дані, або в них. Але ж вони працюють в спеціалізованій службі, напевно, у них більше інформації.
Так і тут, або Microsoft, Oracle, всі розробники опенсорсного PostgreSQL чогось не знають, або ви.

Я оце запитав у ChatGPT, які мови підтримуються в основних СКБД.
У відповіді є неточності, та нехай.
І думаю, а для чого Microsoft та Oracle вкладають гроші і час у підтримку всього цього?
Може, вони не в курсі, що це все непотрібно?

• 
  SQL Server
  
  • Основна: T-SQL
  • Інші офіційні всередині: .NET CLR (C#, VB.NET, F#)
  • Через розширення / інтеграції: R, Python (Machine Learning Services)
• 
  Oracle
  
  • Основна: PL/SQL
  • Інші офіційні всередині: Java (вбудована JVM), C/C++ (extproc), .NET (на Windows)
  • Через розширення / інтеграції: Python, R, Julia (Oracle ML), JavaScript (через JVM)
• 
  PostgreSQL
  
  • Основна: PL/pgSQL
  • Інші офіційні всередині: PL/Perl, PL/Python, PL/Tcl, PL/Java
  • Через розширення / інтеграції: C (UDF) та багато інших через PL Handler (Ruby, R, Lua, Julia)
• 
  MySQL
  
  • Основна: Procedural SQL (Stored Programs)
  • Інші офіційні всередині: немає (короткий запис: — )
  • Через розширення / інтеграції: C/C++ (UDF), зовнішні виклики до Python/Java/PHP через сторонні рішення

Ну, хотілося б якісь аргументи, кейси, аналіз, приклади щодо

практично правильним є використання тільки application layer

.
А то звучить щось на кшалт «Учение Маркса всесильно, потому что оно верно»

Все це вірно, SQL CLR вже скоріше legacy технологія, але деяких випадках все ще має сенс її використовувати.
От що каже ChatGPT, і я з ним згоден:

1. Складна обробка рядків
Регулярні вирази (Regex) для пошуку або заміни тексту.
T-SQL не має повноцінних регулярних виразів, а CLR дозволяє використовувати .NET System.Text.RegularExpressions.
Приклад: пошук та витяг підрядків у великих текстових полях без масивних T-SQL конструкцій.

2. Криптографія
Хешування, шифрування/розшифрування даних.
SQL Server має вбудовані функції (HASHBYTES, EncryptByKey), але для складних алгоритмів або нестандартних форматів часто використовують CLR.

3. Обробка XML/JSON
Якщо потрібно виконати складну навігацію по XML/JSON або трансформацію, CLR може працювати швидше і зручніше, ніж через T-SQL або XQuery.

4. Математичні та статистичні обчислення
Наприклад, тригонометрія, чисельні методи, лінійна алгебра.
CLR дозволяє використовувати .NET бібліотеки (Math.NET, чисельні алгоритми), що інколи значно швидше за T-SQL.

5. Інтеграція з зовнішніми API
Наприклад, виклики веб-сервісів або обробка специфічних даних у форматах, які складно обробляти в чистому SQL.
Це одна з рідкісних, але реальних причин використання CLR у деяких проєктах.

Сам використовував для регулярних виразів, обробки xml і виклику API.

От, наприклад, ви навчаєте свою нейронку на Pandas датафреймах.
Даних побільшало, не вистачає пам’яті, додаєте.
Через деякий час знову невистачає пам’яті, додаєте.
Коли вам це набридне, плюєте на все, розгортаєте кластер Spark і переробляєте весь свій код, написаний непомірним трудом, під PySpark.
Тобто, підбирайте правильну архітектуру — оцінюйте можливі перспективи щодо об’єму даних, мережевого навантаження, вартості тощо.
Для одних рішень бізнес-логіка в SQL Server підійде, для інших ні.
На жаль, в SQL Server тільки вертикальний скейлінг.

В IT-бизнес пришёл в 41 с государственной конторы, сейчас 48, спрос на меня на рынке труда пока есть. А то, что многие считают, что после 40 в IT ПОКА очень мало народу — так это от молодости отрасли. Лет 10 назад в IT компании после 30 лет вообще было сложно попасть.
«Извините, Вам же уже 38! У нас возрастной ценз.» — говорил мне 25-летний PM.
А сейчас спрос превышает предложение, не брезгуют и 50-летними.
Рынок-с, господа!