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

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

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

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

обеспечение целостности данных например, ограничения не всегда применимы.

Триггер не обеспечивает целостность данных. Ссылочную разве что?

что значит не обеспечивает? триггер обеспечивает все, что в его функциональность придет в голову заложить.

Если ты вешаешь триггер на инсерт, будет ли он одной атомарной операцией вместе с инсертом**?

Если у тебя в заголовке процедуры стоит SET XACT_ABORT on, можешь выкинуть свои форен кеи. Ссылочная целостность будет обеспечена.

Если ты не удаляешь строки, а маркируешь их (что правильно), то у тебя вообще не может быть такой ситуации, когда ссылка пробилась. Ты там случаем данные не удаляешь?

Тригера очень полезная вещь. Не поспоришь, что некоторые неправильно их готовят😂
В существующих системах, именно когда нет возможности менять устоявшиеся правила, тригер вас просто спасет. Реальный случай: необходимо организовать партишион схему для одной из таблиц по составному индексу, одно из полей которого на данный момент не существует в этой таблице, но присутствует в связанной. Без инстид тригерра - не реализуется, доп нагрузка при  crud - естественно, зато абсолютный выйгрыш в других аспектах.
Хорошо когда можно вот так взять и перепроектировать структуру, разложить всё как надо и минимизировать использование тригерров, в противном случае без тригерров никуда, использовать надо правильно и как можно реже.

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

вы когда свои триегры радостно везде пихаете, а потом через год работу меняете - новым приходится во всем это копаться (вы же документацию пишите?) и радосто ловить новые неучтенные случаи вашего гениального архитектурного плана.

здесь все в чате всегда всем новичкам советуют не использовать тригеры, если вы знаете как их готовить, то это хорошо, но не надо делать из них best practice и тем более решать ими какие-то бизнес задачи внутри базы данных.

для нечитателей с очень негативным жизненным опытом повторюсь

Привет. Есть таблица с приходами и расходами. Каждая плюсовая строка формирует партию. Партии списываются расходами в порядке очереди (фифо). Может кто подскажет как красиво получить на определенную дату остаток по каждой партии?

Как я вижу без пробежек по курсорам не обойтись?

Не понял, зачем тут, вообще, курсор?
Почему просто не суммировать все приходы и расходы до интересующей даты?

красиво - оконные функции,
просто — подзапросы и группировки

Опять триггерный холивар 😊

Триггеры - всего лишь инструмент. Нужно а) понимать как он работает и б) когда можно/нельзя его использовать.
Триггерофобы обычно не могут похвастаться ни а), ни б)...

Могу лишь добавить, что категорически не рекомендуется использовать триггеры instead of update/delete.
Из-за разного поведения блокировок, в зависимости от TIL и уровня оптимизации инструкции, приведшей к срабатыванию такого триггера.

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

Xact abort + crud решает проблему с констрейнтом. Если у тебя голые таблы наружу висят без процедур, ты скорее всего бекендер.