Спасибо за такой пример!)

Не совсем так. Просто такой подход популярен из-за отсутствия хороших специалистов в базах данных.

Это моё мнение) Впрочем базистов действительно немного.

А теперь посмотри - или получить SQL распарсить выполнить запрос собрать ответ и вернуть назад по сети. И так несколько раз. Или выполнить все внутри БД. Хотя бизнес логику действительно так лучше не делать, отладка отсутвие юнит тестов и т д. А вот сервисные однотипные операции или общие крупные куски - лучше через хранимки и триггеры.

Не переубедили всё равно. Думаю каждый останется при своём.

По мне так нюансов всё равно множество: объём обрабатываемых данных, срочность операций, сложность логики, и другие. Да, мы получим "коробку, в которой что-то происходит быстрее". Имхо, я трижды подумаю, прежде чем туда пихать что-то подобное. Перемиграция на другую СУБД уже осложняется тем, что в нашей не только данные, но и где-то какая-то логика, которую тоже нужно не забыть перенести. Какие-либо изменения могут потребовать изменения в этих хранимках, а забыть о них там очень легко, особенно при изменении штата команды. Стоит только потерять эту экспертизу и потом концов не сыщещь.

Я же сказал обычно в такие сложности не лезут. Навешал редис и ура. Ну или сдал заказчику систему взял новую на новых технологиях.

А если представить задачу, когда оператор в CRM вводит ИНН и нужна проверка контрольной суммы. Доступа к исходному коду CRM у нас нет, а в штате есть опытный разработчик с компетенциями по базам данных. В таком случае можно воспользоваться триггером? Или лучше другой инструмент на стороне БД?

Для проверки ИНН лучше воспользоваться другим методом. А вот выполнить валидациб данных при записи можно, и даже нужно. Но для этого есть констрайны с регексп. Хотя если там сложное - например зависимости полей и прочие условия - это лучше на триггере. Просто регексп плохо читаем и не сильно универсальный.

Благодарю за ответ!