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

[IKA]

Помогите подумать, в чем могут быть преимущества/недостатки использования триггеров на стороне Sql server вместо Ax insert/update/delete?
из очевидных преимуществ :может, проще обращаться к другим sql server -ам
из очевидных недостатков:надо пересоздавать при каждой синхронизации таблицы
Спасибо

[oip]

А в чем состоит ваша задача? Вы вообще про что? Вместо "Ax insert/update/delete" нельзя использовать ничего другого, потому как в этих методах находится/может находиться часть бизнес-логики приложения.

[IKA]

Задача - логгировать определенные изменения данных в другую таблицу. Поэтому думаю, где лучше писать. На первый взгляд, для моей задачи преимуществ писать это на стороне sql не вижу, но, может, есть кие-то тонкости, о которых я не задумываюсь.
record.Insert/update так и останутся в аксапте, поэтому бизнес-логика не пострадает.

[oip]

Чем не устраивает стандартный журнал базы данных? Если не устраивает, то в любом случае что может быть проще, чем перекрыть insert/update в Аксапте? Тем более, сами же пишите, что "надо пересоздавать при каждой синхронизации таблицы". Есть что-то, что вас смущает, раз вы вопрос задали?

[sukhanchik]

Общая идеология программирования в АХ такова - что код нужно писать только в АХ без участия БД. Как бы не хотелось. Представьте себе как Вы будете отлаживать код - из отладчика АХ проваливаться в отладчик SQL? А если Вас сменит товарищ, который не умеет работать с отладчиком на SQL Server? (или вообще БД сменят на оракл ).
Конечно - технически - все можно сделать но подумайте шире - код захочется перенести, возможно Вам в этом не придется участвовать, человек, который переносит код - может не знать:
а) также хорошо SQL Server как Вы - чтобы уметь перенести триггеры
б) что эти триггеры вообще существуют.
Ведь в АХ есть перекрестные ссылки, по которым все видно и которые очевидно не строятся по коду, исполняемому вне АХ

[mazzy]

Цитата:

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

Общая идеология программирования в АХ такова - что код нужно писать только в АХ без участия БД. Как бы не хотелось.

Угу. Кроме того, БД могут быть разные.

[mazzy]

Цитата:

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

Чем не устраивает стандартный журнал базы данных?

Возможно, человек задумывается над тем, чтобы сделать железобетонный лог, который отлавливает даже doInsert/doUpdate и не отключается командой skipDatabaseLog.

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

[oip]

Цитата:

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

Возможно

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

"Вы забыли об этом спросить, но это дом для семейства слепых жирафов" (с) Джоэль
http://russian.joelonsoftware.com/Ar...erviewing.html

[IKA]

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

[mazzy]

Цитата:

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

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

1. а с чего вы взяли, что лог отслеживает только действия пользователей?
2. а почему именно в другую БД? Чем не устраивает вариант логирования в эту же БД, а затем перенос записей в другую БД средствами самой БД?

[petr]

Цитата:

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

Возможно, человек задумывается над тем, чтобы сделать железобетонный лог, который отлавливает даже doInsert/doUpdate и не отключается командой skipDatabaseLog.

Вообще то лог отлавливает doInsert/doUpdate. Специально в свое время проверял (была необходимость). Если сомневаетесь, то в salesLine строки вставляются именно командой doInsert() и лог (журнал БД) по ней работает.

[sukhanchik]

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

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

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

[Alexx7]

Почитал и стало грустно.
Вы помогаете друг другу или играете в "кто умнее" ? Уважаемый IKA примите мои соболезнования.

[gl00mie]

Не грустите понапрасну Форум - это не техподдержка, где задал вопрос - получил ответ, и все - тема закрыта. Очень часто обсуждение уходит в сторону от изначального вопроса, отнюдь не становясь при этом менее интересным другим участникам форума. Опять же, помощь бывает разная: голодному можно дать рыбу, а можно научить ее ловить

[egorych]

Цитата:

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

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

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

[oip]

Цитата:

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

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

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

[egorych]

А недавно кто-то job выкладывал на этот счет с вложеными транзакциями.

[oip]

Вы про это? Там нет примера того, что Аксапта при откатывании транзакций оставляет какой-то "хвост".

[sukhanchik]

Цитата:

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

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

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

[ZVV]

Цитата:

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

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

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

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