Yuri Abele,
вроде как синтаксис создания триггера подразумевает обязательное FOR EACH ROW.
то есть он в любом случае будет выполняться для каждой измененной строки

мы же говорим о строках, а не о полях?

Yuri AbeleХреново! Еще один аргумент миграровать на что-то другое. а в чём собственно проблема обрабатывать построчно?
ну кроме того, что один апдейт десяти записей выполнится быстрее десятка апдейтов по одной. каких таких итераций вы собираетесь избежать?
MSSQL-Books-OnlineThe deleted and inserted tables hold the old values or new values of the rows that may be changed by the user action. а кроме MSSQL-я кто-то еще так умеет?

Yuri AbeleORACLE может и так и так
если не ошибаюсь, в оракле таких встроенных возможностей нет.
можно сделать свой костыль типа создания временных таблиц (аналогов inserted и deleted), заполнять их в триггере for each row, а потом в триггере after statement массово обрабатывать (ну или использовать один compound триггер, но только начиная с 11g).
но вот работать сразу с пакетом измененных записей - не получится.

Yuri AbeleЯ их (тригеры) вообще не люблю - плохой это стиль - но тут пришлось и очень удивился, что в MySQL только построчно.в триггерах и их применении ничего плохого нет, это отличный инструмент для разнообразных целей. иначе бы их не придумывали и не вводили бы. главное знать, что они существуют и учитывать их. а уж какую часть логики заложить в триггеры, а какую вынести наружу - решает архитектор, сообразно целям-задачам и своему опыту (ну и возможностям СУБД само собой).
триггеры в mysql появились относительно недавно, возможно он просто еще "не дорос" до пакетных триггеров.

AkinaТриггер - это костыль. Костыль, позволяющий "втащить" итеративную обработку в групповую. А костыль - это всегда плохо. костыль - плохо. но с чего вдруг триггер является костылём?
у человека куча встроенных триггеров в виде врождённых и приобретенных рефлексов - это разве плохо? зачем переводить дыхание, сердцебиение, выработку гормонов на уровень осознаваемых/контролируемых действий?
зачем мне выносить, например, фиксацию момента времени вставки/изменения записи во внешний механизм, и потом следить еще чтобы использовался каждый раз только этот механизм? Почему я должен доверять
AkinaНо ленивые языковые программисты не хотят программировать сразу в двух точках и изучать все возможности того, что используют - им проще оставаться в рамках одной среды и использовать костыли.а если этих точек не две, а 5-10? а если часть этих точек не подвластна настройке/доработке?
триггер как раз и является одной из "возможностей того, что используют" - это возможность СУБД среагировать на изменение в таблице, запустить какие-либо механизмы, независимо от пути попадания записи в таблицу или радивости/нерадивости разработчика внешнего механизма.

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