|
![]() |
#1 |
Участник
|
Цитата:
Вы считаете, что если некое поле заполнять при помощи SQL-триггера, то выборки по этому полю будут работать быстрее, чем если то же самое поле заполнять средствами Axapta? Цитата:
Сообщение от Ilyaae
При синхронизации, которая пройдет 1 раз, он еще не нужен, а после его включить.
Цитата:
Сообщение от Ilyaae
Так за-то в АХ ничего не ломаем.
![]()
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#2 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
![]() Какая связь между способом заполнения некоего поля и способом его использования (чтения значения этого же поля)?
Вы считаете, что если некое поле заполнять при помощи SQL-триггера, то выборки по этому полю будут работать быстрее, чем если то же самое поле заполнять средствами Axapta? Дело не в том как его заполнить. Смысл в создании и заполнении этого поля. Что даст прирост в скорости выполнения запросов(рассматривает t-sql) Как Вы думаете, спустя месяц..два, разработчки вообще вспомнит о том, что после синхронизации некой таблицы надо в ней вручную поднять SQL-триггер? А если синхронизируется несколько таблиц сразу в автоматическом режиме? Зачем что то поднимать, триггер не рушится, он создан и действует. А синхронизация нужна, до момента запуска триггера. Axapta - это не только ![]() |
|
![]() |
#3 |
Участник
|
Цитата:
" Как Вы думаете, спустя месяц..два, разработчки вообще вспомнит о том, что после синхронизации некой таблицы надо в ней вручную поднять SQL-триггер? А если синхронизируется несколько таблиц сразу в автоматическом режиме? Зачем что то поднимать, триггер не рушится, он создан и действует. А синхронизация нужна, до момента запуска триггера. " ? Триггер, это, конечно, замечательная возможность в SQL. Но, она не имеет ни каких преимуществ перед аксаптовскими "триггерами". (да простят меня аксаптеры). В аксапте это делать намного проще, удобнее и быстрее, чем на SQL, это во вторых, а во-первых, управление данными, таким образом, вы перекладываете на две , скажем так системы, что в итоге может привести к конфликту. Аксапта сама способна сделать то, что может сделать SQL триггер, при этом потребует от вас наименьших затрат, гарантируя при этом минимальное количество рисков.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
|
За это сообщение автора поблагодарили: lev (3). |
![]() |
#4 |
Участник
|
Цитата:
Сообщение от Pustik
![]() В аксапте это делать намного проще, удобнее и быстрее, чем на SQL, это во вторых, а во-первых, управление данными, таким образом, вы перекладываете на две , скажем так системы, что в итоге может привести к конфликту. Аксапта сама способна сделать то, что может сделать SQL триггер, при этом потребует от вас наименьших затрат, гарантируя при этом минимальное количество рисков.
|
|
![]() |
#5 |
Участник
|
В Аксапте у каждой таблицы существуют методы. В том числе и Insert(),Update(),Delete(), которые и будут являться аналогами триггеров на SQL. Перекрывая их, Вы можете написать в них свой алгоритм, который отработает при каждом : добавлении записи - Insert(), обновлении - Update() и удалении - Delete().
Простейший пример можно увидеть посмотрев эти методы на таблице Справочника номенклатуры inventTable. В методах Insert() и Update() автоматически проставляется краткое наименование номенклатуры : X++: this.setNameAlias(); X++: void insert() { #OCCRetryCount ; try { ttsbegin; this.insertInventItemOrderSetup(); this.insertBOMTable(); this.setNameAlias(); super(); ............ } X++: void update() { InventTable this_Orig = this.orig(); ItemGroupId itemGroup_Orig = this_Orig.ItemGroupId; ForecastSales forecastSales; ForecastPurch forecastPurch; ; ttsbegin; this.setNameAlias(); this.inventModelGroup().inventModelType().preUpdateInventTable(this); super(); ............. } X++: public void delete() { BOMTable bomTable; BOMVersion bomVersion; BOMVersion bomVersion2; ; ttsbegin; if( !isConfigurationkeyEnabled(configurationkeynum(BOMVersion)) && this.inventItemType().canHaveBOM()) { while select bomVersion group by bomId where bomVersion.ItemId == this.ItemId notexists join bomVersion2 where bomVersion2.bomId == bomVersion.bomId && bomVersion2.ItemId != this.ItemId { delete_from bomTable where bomTable.bomId == bomVersion.bomId; } } super(); ttscommit; }
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. Последний раз редактировалось Pustik; 12.01.2012 в 13:27. |
|
|
За это сообщение автора поблагодарили: Ilyaae (1). |
![]() |
#6 |
Ищущий знания...
|
Цитата:
А случиться эта синхронизация может когда угодно! Причем даже тогда, когда вы об этой таблице и не вспомните. Например при изменении свойства StringSize у EDT с типом String будет выполнена синхронизация всех таблиц (поясню, вы изменили длину поля ItemId, которое не имеет отношения к вашей таблице, а она отсинхронизировалась и до свидания триггер)! P.S. просто совет, прислушайтесь к людям, и выполняйте изменение с помощью самой аксапты (ведь именно приложение, а не БД, управляет бизнес логикой), меньше проблем будет потом...
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
![]() |
#7 |
Участник
|
Цитата:
Сообщение от lev
![]() Так про то и говорят, что оно дополняет приложение, но только временно, а именно до первой синхронизации таблицы. При синхронизации таблицы триггер удалится.
А случиться эта синхронизация может когда угодно! Причем даже тогда, когда вы об этой таблице и не вспомните. Например при изменении свойства StringSize у EDT с типом String будет выполнена синхронизация всех таблиц (поясню, вы изменили длину поля ItemId, которое не имеет отношения к вашей таблице, а она отсинхронизировалась и до свидания триггер)! P.S. просто совет, прислушайтесь к людям, и выполняйте изменение с помощью самой аксапты (ведь именно приложение, а не БД, управляет бизнес логикой), меньше проблем будет потом... ![]() |
|
Теги |
оптимизация, склад, складская аналитика, складские отчеты |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|