в чем преимущества триггеров

[sukhanchik]

В лог попадет все, что:
а) было настроено попадать (если к примеру, лог будет отключен по событию update, то при событии update ничего туда попадать не будет)
б) не было принудительно отключено в коде через параметр skipDatabaseLog

Кстати - еще один минус в сторону триггеров. Представьте себе - возникла ситуация, когда надо будет проджобить (разово изменить (удалить/добавить) записи) табличку в АХ. При этом ну никак нельзя эти изменения переносить во вторую БД. Это в начале кажется что такого не было и быть не может. По факту - такие ситуации возникнут - 100% рано или поздно. В АХ лог можно отключить, а вот с триггерами в БД поковыряться придется. А ситуация может быть простая - рассинхронизация Ваших БД. Например, восстанавливали ее из бекапа.

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

[egorych]

Цитата:

Сообщение от sukhanchik

...Кстати - еще один минус в сторону триггеров...

Могу добавить + к триггеру - например, идет удаление чего-то (строка отгрузки, например) - частенько в алгоритме присутствует несколько транзакций в разных классах, методах... Вдруг обрыв (ну хз - АОС упал, сеть порвалась и др.) останется хвост (частенько у себя чистим - только не надо про кривых программеров и т.д. - Косяпта сама не всегда идеально с транзакциями работает) - триггер такого не допустит - либо все удалится, либо ничего.
То-же само и при модификации строки.

[oip]

Цитата:

Сообщение от egorych

Косяпта сама не всегда идеально с транзакциями работает

Есть конкретный пример?

[sukhanchik]

Цитата:

Сообщение от egorych

Могу добавить + к триггеру - например, идет удаление чего-то (строка отгрузки, например) - частенько в алгоритме присутствует несколько транзакций в разных классах, методах... Вдруг обрыв (ну хз - АОС упал, сеть порвалась и др.) останется хвост (частенько у себя чистим - только не надо про кривых программеров и т.д. - Косяпта сама не всегда идеально с транзакциями работает) - триггер такого не допустит - либо все удалится, либо ничего.
То-же само и при модификации строки.

Не.. ну это понятное дело - что БД за транзакциями следит. Аксапта сама за ними следить не может - она может только давать команды их открывать/закрывать. Просто когда код выполняется из Аксапты - потенциально возможен случай - когда (если код написан некорректно) - останутся "хвосты". Но это скорее вопрос к разработчику.
Но тем не менее - если бы утверждение, что "триггер не пропустит" было бы неверно - то про триггер никто бы не вспоминал. Ни у кого же не возникает (надеюсь!) мысли натравить 2 приложения на одну базу и передавать управление из одной Аксапты в другую

[ZVV]

Цитата:

Сообщение от egorych

Могу добавить + к триггеру - например, идет удаление чего-то (строка отгрузки, например) - частенько в алгоритме присутствует несколько транзакций в разных классах, методах... Вдруг обрыв (ну хз - АОС упал, сеть порвалась и др.) останется хвост (частенько у себя чистим - только не надо про кривых программеров и т.д. - Косяпта сама не всегда идеально с транзакциями работает) - триггер такого не допустит - либо все удалится, либо ничего.
То-же само и при модификации строки.

В данном случае это именно про кривых программеров, и ни о чём более...

По сути ответ был дан в самом первом посте самим же топикстартером...
++ "близость" к данным, как следствие независимость от приложения и, в какой-то степени, скорость работы
-- потенциальная постоянная "рассинхронизация" с приложением