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

[IKA]

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

[oip]

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

[IKA]

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

[oip]

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

[mazzy]

Цитата:

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

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

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

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

[oip]

Цитата:

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

Возможно

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

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

[petr]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

Заметно тормозит систему.
Ситуация у нас такая, что идут постоянные бодания на тему:"кто накосячил". Несколько систем работает в связке, причем регулярно дорабатываются. Регулярно, посреди транзакции падает одна из систем или связка между ними. Пользователи с админскими правами тоже активно что-то правят. Регулярно обнаруживаются косяки и начинается поиск виноватых. Чтобы прикрыть задницу, ведется логгирование в файлах всего что входит/выходит через BC и основных таблиц в системном логе.
Т.к. в лог пишут все и сразу, он временами начинает задумываться над своей тяжелой жизнью. При этом гражданин должен ждать у конторки, пока чиновник выпишет ему документ лишние 10 секунд. Гражданин расстраивается. Чиновник расстраивается от того, что гражданин расстроился. Другой гражданин расстроился из-за того, что очередь образовалась. Все unhappy. Надо что-то делать.

AX 4.0.2501.116

[AlexeyS]

Цитата:

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

Заметно тормозит систему.
Ситуация у нас такая, что идут постоянные бодания на тему:"кто накосячил". Несколько систем работает в связке, причем регулярно дорабатываются. Регулярно, посреди транзакции падает одна из систем или связка между ними.

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

[Logger]

Цитата:

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

...Пользователи с админскими правами тоже активно что-то правят. Регулярно обнаруживаются косяки и начинается поиск виноватых. Чтобы прикрыть задницу, ведется логгирование в файлах всего что входит/выходит через BC и основных таблиц в системном логе.
AX 4.0.2501.116

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

[gl00mie]

Цитата:

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

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

По-моему, это - почти чисто админская (в смысле DBA) проблема, а не аксаптовая. Да, есть одна таблица, в которую куча народу накидывает кучу записей, да, она может разрастаться до десятков процентов от размера всей базы, да, иногда вставка записи в нее может задумываться на несколько секунд, тормозя обработку данных, удлинняя транзакции, приводя к дополнительным блокировкам и т.п. Ну и что, из-за этого сама идея перестает быть хорошей? Один из вариантов решения - партицирование таблицы по какому-то левому полю, значение которого хорошо распределено между сессиями. Можно добавить поле по аналогии с LedgerBalancesDimTrans.LedgerBalancesVariant, которое заполнять каким-нить остатком от деления кода сессии на константу, и вот по этому полю партицировать таблицу. А еще регулярно избирательно чистить ее, чтобы она не разрасталась до непомерных размеров, - для этого может потребоваться дополнительное партицирование по LogTableId.

[sukhanchik]

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

[mazzy]

Цитата:

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

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

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

[sukhanchik]

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

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

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

[egorych]

Цитата:

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

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

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

[oip]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

[ZVV]

Цитата:

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

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

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

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

[Alexx7]

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

[gl00mie]

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