find() vs. join

[axaLearner]

Возник вопрос: что производительнее
while select purchLine
{
inventTable = InventTable::find(PurchLine.itemId);
some action;
}
или
while select purchLine
join inventTable
where purchLine.ItemId == inventTable.ItemId
{
some action
}

?

[sukhanchik]

гым... ну если нет никаких подводных камней - то по идее - первый вариант по определению дольше; существенно дольше. Связано это с тем что во втором случае исполняется один SQL-запрос, а в первом - по кол-ву записей в purchTable. А вообще-то есть профайлер - он более точно даст ответ.
В частности аналогичная ситуация в Transact-SQL для SQL Server однозначно решается в пользу второго варианта.

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

[belugin]

а кеширование?

[vic_z]

Цитата:

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

а кеширование?

Так в кеше тоже надо сначала найти нужную запись, что тоже не на пользу производительности. А в случае join система будет только с одним курсором работать.
Да и не всегда возможно InventTable закешировать.

[mazzy]

Цитата:

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

Возник вопрос: что производительнее
while select purchLine
{
inventTable = InventTable::find(PurchLine.itemId);
some action;
}
или
while select purchLine
join inventTable
where purchLine.ItemId == inventTable.ItemId
{
some action
}

?

В общем случае второй вариант.

Но зачастую - первый. Тут правильно говорили о кэшировании.

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

Т.е. правильно вопрос выглядит так:
что лучше

while select purchLine
{
    inventTable = InventTable::find(PurchLine.itemId);
    some action;
    if( some1 ) someTable1::find(PurchLine.someId1);
    if( some2 ) someTable2::find(PurchLine.someId2);
    if( some3 ) someTable3::find(PurchLine.someId3);
    ...
}

или

while select purchLine 
                   join inventTable
                   where purchLine.ItemId == inventTable.ItemId
                   join someTable1
                   where purchLine.someId1 == someTable1.someId
                   join someTable2
                   where purchLine.someId2 == someTable2.someId
                   join someTable3
                   where purchLine.someId3 == someTable3.someId
                   ...
{
    some action
}

А здесь ответ уже далеко не однозначен.

По идее надо бы еще говорить о плане запроса и о кэшировании запросов на СКЛ... О том, насколько лучше СКЛ оптимизирует простые запросы (даже если их много) по сравнению со сложными (но редкими).

Кроме этих соображений есть еще одно - только первый вариант позволит сделать универсальный и развесистый код. Только первый вариант позволит скрыть детали реализации.

Вы пишете свой метод для работы с номенклатурой внутри цикла по строкам закупки. Ваш метод получает в качестве параметра код номенклатуры. Как эту номенклатуру получили вас в вашем методе не волнует. Ваш метод занимается только своей работой. В таком случае бывает удобнее внутри вашего метода сделать лишний find.

[axaLearner]

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

[Maxim Gorbunov]

Цитата:

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

если Вы не "системщик" в Аксапте, а "прикладник", т.е. пишете на слое cus-usr, то универсальность в ущерб производительности НЕДОПУСТИМАЯ роскошь.

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

Цитата:

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

Указанные запрос - не супер сложный. Кроме того, медленные предикаты СКЛя Аксапта попросту не пропускает (хэвинг), если мне не изменяет память.

Правильнее говорить не "не пропускает", а "не использует при интерпретации". Да и не "долгие" инструкции она не пропускает, а "не универсальные" .

Цитата:

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

Т.е. супер-сложный-долгий запрос у Вас создать не получится.

Нет ничего невозможного

Цитата:

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

Мало того, берусь утверждать, что самое скромное кол-во простых запросов взамен сложного по тому же результату будет НА ПОРЯДКИ дольше в исполнении-получении.

Простое сравнение, однако, не имеет практической ценности. Всегда надо исходить из контекста конкретной задачи.

Цитата:

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

...подтверждено пунктом 1 раздела Оптимизация Бест практис.

А вот это очень правильное замечание. Согласно BP, сервер БД - наиболее приоритетное место для выполнения бизнес-логики. Другими словами, если у Вас есть возможность в Вашей задаче использовать СУБД, не нарушая при этом других принципов разработки в Axapta, предпочтение следует отдавать именно этому варианту. В большинстве случаев это, правда, касается использования массовых обновлений данных и выборок с агрегирующими функциями.