Ну да, триггер на хранимую процедуру, возможно выразился не совсем верно, но имел в виду именно это

1) Я не могу на 100% сказать, что через ORM нельзя, но на 99% могу. Вряд ли.
2) Даже если было бы можно - лучше не нужно.

Если это прям свойство самих данных, но по-хорошему триггер в БД.
Но если не хочется усложнять работу с БД, то через листнер

Это типичная задача поддержания целостности БД, которая должна решаться средствами СУБД. Попытки сделать это через ORM являются костылями в 100% случаев

я хотел через листнер, но почитав доки закралась мысль, что там нет таких возможностей. Там можно среагировать до или после срабатывания операции, но нельзя к примеру привязать к конкретному полю

ладно, пойду разбираться в триггерами и процедурами, спасибо

С одной стороны да.
Но сейчас часто уходят от того, чтобы делать это всё на уровне СУБД, когда с БД работает только одно приложение. А на СУБД оставляют "таблички".
Без представлений, без ХП и триггеров.

Так просто проще разрабатывать, держа логику в приложении, даже, если она связана с целостностью данных.

В БД придётся всё это ещё через миграции делать

Во первых, что бы сразу закрыть вопрос для топикстартера - может быть где-то это будет хоть немного уместно, но не в несте. Местные листенеры спроектированы из рук вон плохо.

А при чём тут нест?) Он же за это не отвечает

Ну вот в этом и вся проблема - он за это не отвечает. Просто вопрос был задан в чате по несту, я предполагаю, что автор использует связку Nest + TypeORM.
И листенеры вообще никак не взаимодействуют с экосистемой неста

Ну это завязка на ORM, да.
Да, это не очень чисто.
Но на порядок проще, чем сделать чисто

Интересно, кстати, засунет ли TypeORM это всё в одну транзакцию

Ну это субъективно уже:)
Лично мне на порядок проще написать хранимку на несколько строк и СУБД будет гарантировать мне целостность.
А тут вообще никаких гарантий.

Очень хороший вопрос;)

Просто мне никогда не нравилось, когда миграции становятся сложнее, чем обновление схемы. Когда в них появляется логика приложения.
Но можнт я просто не умею их готовить

За простоту

https://docs.nestjs.com/techniques/database#subscribers

Я вот тут пример читаю, и даже в примере не осветили кейс каскадного обновления. Потому что стыдно) Ты сущность в несте обновляешь одним методом, а в субскрайбере уже другим должен. Причём ещё и сам должен разобраться как именно.

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

Просто как только БД становится больше, чем просто "табличками", например, туда прошёл один триггер, начинаются вопросы о распределении другой логики.
А не пора ли навесить гору view-шек? А вот эту обработку результата запроса перекинуть в ХП?
А потом логики становится много, а БД масштабировать не так приятно.

Я вообще разработку приложения начинаю в DataGrip. И только когда там всё уже готово, открываю WebStorm, линкую TypeORM сущности с таблицами/вьюхами и вывожу тонкий API.
Я не понял, про какое именно масштабирование БД вы говорите. Если это про горизонтальное масштабирование - да, это отдельная наука, но до момента, когда вертикально масштабироваться уже некуда, ещё надо дорасти.
Если масштабирование с точки зрения поддержания кода, то многие здесь недооценивают возможности организации. Просто здесь немного другие правила, но эти правила проверены временем, их надо лишь понять. Если правильно всё спроектировать, то поддерживать будет проще, чем на на том же NestJS.

Я про горизонтальную, да.
Просто если на СУБД перекидывается в том числе какая-то обработку данных (или что мы там в view/ХП делаем?), то это нагрузка, которая перетекает из легко мастшабируемого приложения в тяжеломастабируемую СУБД