Почему запрос CustTransOpen именно такой?

[mazzy]

Давно интересовал вопрос. А сейчас столкнулся снова.

А почему запрос CustTransOpen определен в AOT\Query именно в таком порядке?
Почему внутри CustTable находится CustTransOpen, а уже к нему прицеплен CustTrans?

да, я в курсе, что в SQL запросе все это отобразиться в inner join и серверу SQL все равно в каком порядке.
Но аксапте то не все равно.

аксапта генерит relation между соседними таблицами. эти связи идут в запрос.
у аксапты есть метод change.
у аксапты есть хинт forcenested.
для аксапты порядок важен.

почему в Query именно такой порядок таблиц?

[gl00mie]

Мне кажется, идея была в том, что надо максимально эффективно сужать выборку. Видимо, "автору" запроса показалось, что лучше всего сужают выборку фильтры по клиентам, затем - по открытым проводкам, а уже потом - по всем подряд проводкам. А что оптимизатор запросов умеет менять порядок объединения таблиц в запросе, при этом не учитывалось.

[fed]

Цитата:

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

Мне кажется, идея была в том, что надо максимально эффективно сужать выборку. Видимо, "автору" запроса показалось, что лучше всего сужают выборку фильтры по клиентам, затем - по открытым проводкам, а уже потом - по всем подряд проводкам. И что оптимизатор запросов умеет менять местами порядок объединения таблиц в запросе, при этом не учитывалось.

И, возможно, в момент написания запроса, основной БД была внутренняя Database Engine Дамгаарда, которая не факт что особо хорошо умела запросы оптимизировать. Отсюда же и indexHint во всех find()/exists() методах может рости.

[mazzy]

хм... уточню. интересует не столько "почему CustTable первая",
сколько "почему вторая CustTransOpen"

вроде естественный логический порядок: CustTable - CustTrans - CustTransOpen
но здесь порядок неестественно вывернут.

да, согласен, что это очень старый объект. старый как гавно мамонта.
да, согласен, что скорее всего имела место какая-то оптимизация.
вопрос - какая именно? почему именно так?

просто не вижу никаких преимуществ от такого порядка по сравнению с естественным.
а после введения договоров в custTrans, запрос вообще стал...

"все в неестественных позах. наверное, что-то случилось" (С)
http://www.youtube.com/watch?v=doeTUFRu3-A

[Ace of Database]

Может это из-за того, что к CustTrans потом пользователи могут приджойнить другие таблицы, например, LedgerTrans, а потом к этой другой таблице еще чего-нибудь приджойнить.
А если последней сделать таблицу к CustTransOpen, то к ней мало что можно приджойнить. А к непоследней таблице в Query нельзя джойнить более одной таблицы, так как в этом случае Query начинает неправильно работать.

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

Пример:

//Вариант 1) - который будет работать:
CustTable
|
------>CustTransOpen
          |
          ----------------->CustTrans
                                 |
                                 -------------->LedgerTrans
                                                      |
                                                      ----------->LedgerTable

//Вариант 2) - который не будет работать:
CustTable
|
------->CustTrans
           |
           -------------->LedgerTrans
           |                    |
           |                    ----------->LedgerTable
           |-------------->CustTransOpen

[Владимир Максимов]

Цитата:

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

хм... уточню. интересует не столько "почему CustTable первая", сколько "почему вторая CustTransOpen"

вроде естественный логический порядок: CustTable - CustTrans - CustTransOpen но здесь порядок неестественно вывернут.

Так gl00mie сделал вполне логичное предположение. Автор запроса, предположительно, думал, что механизм SQL-запросов работает по принципу вложенных циклов (а может, первые версии Damgaard так и работали ).

Тогда все логично. В рамках одного клиента количество записей в CustTransOpen должно быть существенно меньше, чем количество записей в CustTrans.

[Ace of Database]

В поддержку моей теории попробуйте выполнить следующий джоб.
Видно, что если таблица CustTrans непоследняя, и к ней приджойнить другие таблицы, то Аксапта генерирует неправильный запрос.

static void Job782(Args _args)
{
    Query                   query = new Query();
    QueryRun                queryRun;
    QueryBuildDatasource    qbdsCustTable;
    QueryBuildDatasource    qbdsCustTrans;
    QueryBuildDatasource    qbdsCustTransOpen;
    QueryBuildDatasource    qbdsLedgerTrans;
    QueryBuildDatasource    qbdsLedgerTable;

    ;
    //-->правильно работает
    query = new Query();
    qbdsCustTable = query.addDataSource(tableNum(CustTable));
    qbdsCustTransOpen = qbdsCustTable.addDataSource(tableNum(CustTransOpen));
    qbdsCustTrans = qbdsCustTransOpen.addDataSource(tableNum(CustTrans));
    qbdsLedgerTrans = qbdsCustTrans.addDataSource(tableNum(LedgerTrans));
    qbdsLedgerTable = qbdsLedgerTrans.addDataSource(tableNum(LedgerTable));

    queryRun = new QueryRun(query);
    info(queryRun.query().dataSourceNo(1).toString());
    //<--правильно работает
    
    
    //-->неправильно работает
    query = new Query();
    qbdsCustTable = query.addDataSource(tableNum(CustTable));
    qbdsCustTrans = qbdsCustTable.addDataSource(tableNum(CustTrans));
    qbdsCustTransOpen = qbdsCustTrans.addDataSource(tableNum(CustTransOpen));
    qbdsLedgerTrans = qbdsCustTrans.addDataSource(tableNum(LedgerTrans));
    qbdsLedgerTable = qbdsLedgerTrans.addDataSource(tableNum(LedgerTable));

    queryRun = new QueryRun(query);
    info(queryRun.query().dataSourceNo(1).toString());
    //<--неправильно работает
}

[Ace of Database]

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

[Logger]

Цитата:

Сообщение от Ace of Database

В поддержку моей теории попробуйте выполнить следующий джоб.

А если поставить fetchMode(fetchMode::one2one) ?

[Ace of Database]

One2One правильно работает.
Но на формах вроде бы нельзя в свойствах датасурса изменить FetchMode.
На query можно, на формах - нельзя.

[S.Kuskov]

Цитата:

Сообщение от Ace of Database

Но на формах вроде бы нельзя в свойствах датасурса изменить FetchMode. На query можно, на формах - нельзя.

На формах добавляемые источники цепляются через ExistsJoin

[Ace of Database]

Фишка в том, что свойство fetchMode можно установить только у подчиненного датасорса.
А на форме нет иерархии в источниках данных. Поэтому на форме этого сделать нельзя.
По крайней мере так было в AX2009.

[Ace of Database]

Цитата:

Сообщение от S.Kuskov

На формах добавляемые источники цепляются через ExistsJoin

А как же тогда из них выводить данные в контролы на форме?

[S.Kuskov]

Цитата:

Сообщение от Ace of Database

А как же тогда из них выводить данные в контролы на форме?

Я думал вы о пользовательских фильтрах Ctrl+F3

[Ace of Database]

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

[S.Kuskov]

Цитата:

Сообщение от Ace of Database

Фишка в том, что свойство fetchMode можно установить только у подчиненного датасорса.
А на форме нет иерархии в источниках данных. Поэтому на форме этого сделать нельзя.
По крайней мере так было в AX2009.

Разрешите ещё позанудствовать. В AX2009 уже можно прописать конкретный Query в свойствах корневого узла Data Sources. Собственно все новые формы, которые *ListPage по такому принципу и сделаны.

[Ace of Database]

Цитата:

Сообщение от S.Kuskov

Разрешите ещё позанудствовать. В AX2009 уже можно прописать конкретный Query в свойствах корневого узла Data Sources. Собственно все новые формы, которые *ListPage по такому принципу и сделаны.

С использованием этой технологии все равно все таблицы разворачиваются в плоскую одноуровневую иерархию на форме, без подчиненных датасорсов, у которых можно было бы изменить свойство FetchMode. И я сомневаюсь, что форма на лету подхватит значение этого свойства из прописанного query в корневом узле Data Sources

[Ace of Database]

Хотя нет, свойство FetchMode наблюдается при таком подходе

[SRF]

Возможно данные из CustTrans'а изначально вообще не предполагали забирать.

Первые два DS содержат узел Sorting(+ св-во update выставлено в true), которого нет в третьем DS, и соответственно сейчас его вообще нет в новых объектах Query, так что его могли попросту добавить уже после того как изначально сформировали сам объект, при этом уже потом не захотели менять порядок.

PS. Попытка добавить узел Order by для данного запроса приводит к ошибке - Сочетание сортировки старого типа и новых предложений Group By или Order By в рамках одного запроса не допускается.