dynamicsaxtraining: Select statement patterns

[Blog bot]

Источник: http://www.dynamicsaxtraining.com/ti...ement-patterns
==============

This article contains descriptions of select statement patterns that can be used in the Microsoft Dynamics AX (Axapta).

The list of select statement patterns provided is as follows:

1. Enable/Disable condition
2. Switch condition
3. Enable/Disable join table with condition

Enable/Disable Condition

Use this pattern when the condition in the “where” clause is dependant of a parameter.
For example, we need to perform some procedure with either all Customer or Customers with invoice account only. It depends on the User input parameter. We create a periodic job with the following dialog box:

Process Customers


We will assume that the Customer with invoice account check box has the dialogField name in the code.

The select statement will have the following view in the “run” method:

while select custTable
where (!dialogField.value() || custTable.InvoiceAccount != '')

If the check box is selected, !dialogField.value() returns false and custTable.InvoiceAccount != ” will be taken into account. If the check box isn’t selected, !dialogField.value() returns true (so there is no sense what return the custTable.InvoiceAccount != ” condition). In other words, if the check box is selected, only Customers with Invoice accounts will be searched. Otherwise, all Customers will be searched.

General structure looks as follows: where (!EnableConditionFlag || condition)

Switch Condition

Use this pattern when either one or another condition dependant of parameter must be applied to the select statement.

For example, we need to perform a procedure with items of either a BOM item or items of other item types. We need to create a periodic job with a dialog box. The dialog box contains only one BOM type checkbox. We will assume that the BOM type check box has the dialogField name in the code.

In the run method, we write the following select statement:

while select inventTable
where ((!dialogField.value() && inventTable.ItemType != ItemType::BOM) ||
       (dialogField.value()  && inventTable.ItemType == ItemType::BOM))

If the BOM type check box is selected, the first parenthesis returns false and everything depends on the second parenthesis where the inventTable.ItemType == ItemType::BOM clause is checked. If the BOM type check box isn’t selected, the second parenthesis returns false and everything depends on the first parenthesis where the inventTable.ItemType != ItemType::BOM clause is checked. In other words, if the check box is selected, the only BOM item will be searched. Otherwise, only not BOM items will be searched.

General structure looks as follows: where ((!Condition2Flag && condition 1) || (Condition2Flag && condition 2))

Enable/Disable Join Table with Condition

Use this pattern when a joined table with a condition can either contain records or be empty.

For example, we need select sales orders without Recipient or terminated Recipient. The SalesTaker field in the SalesTable table stores the Recipient ID. The Status field in the EmplTable table stores the Recipient’s status (None, Employed, or Resigned).

The select statement has the following view:

while select SalesTable
notexists join EmplTable
where EmplTable.EmplId == SalesTable.SalesTaker &&
      EmplTable.status != HRMEmplStatus::Resigned

If EmplTable.status is Resigned or the Sales table record doesn’t have the Recipient, the Sales table record will be selected.

General structure looks as follows: notexists join where && (condition != required value)

If you know other interesting patterns, please write them in the comments

Technorati Tags: select statement, select statement patterns, where clause



Источник: http://www.dynamicsaxtraining.com/ti...ement-patterns

[Wamr]

и главный pattern - не используйте эти patterns
используйте Query & QueryRun

[Volodymyr]

Почему? Интересно что отработает быстрее Query или select?

[lev]

Цитата:

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

Почему? Интересно что отработает быстрее Query или select?

Одинаково должно отрабатывать по идее И то и другое отсылает сформированный запрос к базе.
Не один раз проводил тесты у себя, время выполнения всегда было идентично

Тут скорее вопрос в читаемости кода, и в удобности использования синтаксиса, и на мой взгляд, все зависит от ситуации

[oip]

Цитата:

If you need user interaction regarding the data you need processed, a query is the preferable way

[Volodymyr]

Спасибо! Вобщем то если это переменная не из юзер интерфейса, то можно использовать. Я например очень часто первым Enable/Disable пользуюсь.

[gl00mie]

Подобные публикации так и побуждают понудеть...

Цитата:

Сообщение от Blog bot

while select custTable
where (!dialogField.value() || custTable.InvoiceAccount != '')

В игрушечных базах оно, может, и без разницы, но в реальной жизни было замечено, что оптимизатор запросов СУБД совершенно по-разному реагирует на условия вида custTable.InvoiceAccount != '' и custTable.InvoiceAccount > '' - по смыслу они вроде как идентичны, но оптимизатору запросов так почему-то не кажется. К слову, и само ядро, если в запросе указать просто custTable.InvoiceAccount (неявно приводя InvoiceAccount к булевскому типу), формирует запрос с условием > '', а не != ''.

Цитата:

Сообщение от Blog bot

while select SalesTable
notexists join EmplTable
where EmplTable.EmplId == SalesTable.SalesTaker &&
      EmplTable.status != HRMEmplStatus::Resigned

Вот это просто вошлебный пример! Фильтрация по неиндексированному полю SalesTable, да еще и с notexists join - вернейший способ получить полное сканирование таблицы с подзапросами к подчиненной таблице на каждую запись в SalesTable.

Цитата:

Сообщение от Blog bot

General structure looks as follows: notexists join where && (condition != required value)

Скорее general structure looks as follows: не используйте notexists join на сколь-нибудь больших выборках - зачастую тупо перебрать записи, или закэшировать данные из подчиненной таблицы, или использовать какой-нить RecordSortedList для избавления от дублирующихся по определенным критерями записей оказывается с точки зрения производительности намного предпочтительнее. Вот уж действительно:

Цитата:

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

и главный pattern - не используйте эти patterns
используйте Query & QueryRun

[Volodymyr]

Привет. Кажется не туда копать стали.
Как по мне интерес представляет именно "шаблон", а не условие.
Структура первая, вида :

while select custTable
where (!dialogField.value() || custTable.InvoiceAccount != '')

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

Насчет notexists join опять же дело рук каждого.

Соглашусь что примере приведены не самые лучшие.
Но идея хорошая.

[gl00mie]

Мне лично Query больше нравится тем, что:

• можно разбить логику построения запроса на несколько методов, а их - выборочно перекрывать в различных классах-наследниках; для while select нужно либо переписывать запрос целиком, либо в базовом классе предусматривать все возможные условия в запросе и цеплять их тем способом, который был представлен (!flag || condition), что не прибавляет коду наглядности и понятности;
• после добавления всех нужных условий по Query легко увидеть без включения трассировки, какой же в результате запрос получился;
• Query можно передать в другой кусок кода, который не знает, как он был сформирован, а только знает, записи из какой таблицы нужно выбирать;
• Query можно легко переделать для рассчета каких-нить агрегатов вместо перебора записей (бывает, люди хотят видеть на форме поле с суммой по всем записям, удовлетворяющим текущему запросу, - с Query это сделать проще простого);
• в Query не надо извращаться, если какой-то datasource нужно цеплять только по определенному условию, потому что этому datasource'у можно сказать enabled(false) - и он уже не попадет в запрос;
• при использовании Query по умолчанию включена RLS - в случае чего, не надо потом бегать и в куче мест дописывать перед запросом salesTable.recordLevelSecurity( true ).

[Vadik]

Цитата:

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

Фильтрация по неиндексированному полю SalesTable, да еще и с notexists join - вернейший способ получить полное сканирование таблицы с подзапросами к подчиненной таблице на каждую запись в SalesTable

Я вам не скажу за всю Одессу, но на MSSQL not exists join давно уже вроде как разрешается через right anti semi join с разовым table\index scan-ом, не так уж все и страшно, как может показаться

Цитата:

Структура первая, вида :

while select custTable
where (!dialogField.value() || custTable.InvoiceAccount != '')

Позволяет включать выключать любое условие

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

[Wamr]

вот к чему в конечном итоге приводит любовь к "хорошей идеи"

    while select
    sum(Qty), sum(costAmountPosted), sum(costAmountAdjustment) from InventTrans
    group by ItemId
    where
    (!itemId || InventTrans.ItemId == itemId)
    &&
    (
        (
            !dateFrom
            ||
            (
                InventTrans.DatePhysical > dateFrom
                ||
                (
                    isTime
                    &&
                    (
                        InventTrans.DatePhysical == dateFrom &&
                        (
                            InventTrans.GM_DatePhysical > dateFrom
                            ||
                            (
                                InventTrans.GM_DatePhysical == dateFrom &&
                                InventTrans.AX_TimePhysical >= timeFrom
                            )
                        )
                    )
                )
            )
        )
        &&
        (
            !dateTo
            ||
            (
                InventTrans.DatePhysical < dateTo
                ||
                (
                    isTime
                    &&
                    (
                        InventTrans.DatePhysical == dateTo &&
                        (
                            InventTrans.GM_DatePhysical < dateTo
                            ||
                            (
                                InventTrans.GM_DatePhysical == dateTo &&
                                InventTrans.AX_TimePhysical < timeTo
                            )
                        )
                    )
                )
            )
        )
    )
    &&
    (
        InventTrans.StatusReceipt == StatusReceipt::Purchased ||
        InventTrans.StatusReceipt == StatusReceipt::Received ||
        InventTrans.StatusIssue == StatusIssue::Sold ||
        InventTrans.StatusIssue == StatusIssue::Deducted
    )
    && InventTrans.TransType == InventTransType::Sales
    join salesTable group by GM_SalesOperationType where
    salesTable.SalesId == inventTrans.TransRefId
    join inventDim group by inventDimDefect where
    inventDim.inventDimId == inventTrans.inventDimId &&
    (!defect || inventDim.inventDimDefect == defect)
    exists join GM_CalcInventLocationOperational where
    dataAreaAdmin ||
    (!dataAreaAdmin && GM_CalcInventLocationOperational.InventLocationId == inventDim.InventLocationId)
    exists join GM_CalcInventLocationAdministrative where
    (
        (
            dataAreaAdmin &&
            GM_CalcInventLocationAdministrative.CalcInventLocation == GM_CalcInventLocation &&
            GM_CalcInventLocationAdministrative.InventLocationId == inventDim.InventLocationId
        )
        ||
        (
            !dataAreaAdmin &&
            GM_CalcInventLocationAdministrative.InventLocationId == GM_CalcInventLocationOperational.AdministrativeInventLocationId &&
            GM_CalcInventLocationAdministrative.CalcInventLocation == GM_CalcInventLocation
        )
    )