2 while select или join?

[_scorp_]

Я всегда считал, что join таблиц отрабатывает быстрее чем 2 while select`а. Но вот увидел в коде двойной while select и решил "исправить". После переписывания запроса на join код стал выполняться дольше. Написал простой job

static void JobJoin(Args _args)
{
    SalesTable      SalesTable;
    SalesLine       SalesLine;
    int             startTime, endTime, i;
    ;

    startTime = timenow();
    while select SalesTable
    {
        while select SalesLine
           where SalesLine.SalesId == SalesTable.SalesId
        {
            i++;
        }
    }
    endTime = timenow();
    info(strFmt("2 while select: %1, i = %2", endTime - startTime, i));

    i = 0;
    startTime = timenow();
    while select SalesTable
        join SalesLine
            where SalesLine.SalesId == SalesTable.SalesId
    {
            i++;
    }

    endTime = timenow();
    info(strFmt("join: %1, i = %2", endTime - startTime, i));
}

У меня получилось (Ax 3.0 SP3 KR2, SQL2005 SP2)

2 while select: 99, i = 56347
join: 129, i = 56347

Получается что 2 while select'а отрабатывают быстрее Может кто нибудь дать научное обоснование сему явлению?

[Logger]

1. Для джоина мог быть выбран неудачный план запроса, так что формироание выборки могло занять слишком много времени.
2. Объем прокачанных данных во втором случае выше, так как для каждой salesLine передавалась еще и salesTable - больше клиент серверных вызовов было.

но скорее всего п.1

[petr]

Какой способ будет быстрее и насколько зависит от отношения количества записей в salesTable и salesLine.

При одной записе в salesTable и 100 в salesLine - быстрее будет while select - см. пред. пост.

При одинаковом кол-ве записей в salesTable и salesLine - быстее будет join.

[_scorp_]

Цитата:

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

Объем прокачанных данных во втором случае выше, так как для каждой salesLine передавалась еще и salesTable - больше клиент серверных вызовов было.

Получается, что на тонком клиенте лучше использовать 2 while select.

[ZVV]

Провёл небольшие "исследования", вот некоторые выкладки. Мысли в конце.

Цитата:

Oracle, Master\Detail:
2 while select: 400, i = 128285
join: 255, i = 128285
Причём, если аналог прокрутить на БД с использованием PL\SQL, то результаты - 18 и 14 сек! Чувствуется разница. Это на тему влияния RPC и перекачки данных по сети...
Но пропорции времени в пользу join.
На бОльших объёмах - разница ещё больше.

Oracle, 2theSameTables:
2 while select: 195, i = 10213
join: 23, i = 10213
Пропорции (сторона) сохраняются (и даже увеличиваются) при одинаковом кол-ве записей

MSSQL2005, Master\Detail:
2 while select: 45, i = 68825
join: 148, i = 68825
На сиквеле действительно картина обратная

MSSQL2005, 2theSameTables:
while select: 222, i = 68825
join: 57, i = 68825
Пропорции меняются на обратные

Почему так происходит? когда идёт соединение маленькой + большой таблиц сиквел предпочитает использовать в Nested Loop доступ к первой таблице по кластерному индексу. Во втором случае, когда 2 большие одинаковые таблицы - full scan. Ко второй таблице по индексу в обоих случаях. Похоже за счёт этого такая картина... Хотя я всё равно не понимаю почему такая большая разница... Это скорее вопрос к гуру сиквела, почему cluster index scan так тормозит....

Oracle же в обоих случаях использует hash join.
но, даже если уговорить его использовать нестедлуп, то картина не менятся особо - всё равно джоин быстрее...

[ZVV]

Цитата:

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

Получается, что на тонком клиенте лучше использовать 2 while select.

В общем случае - крайне спорное утверждение.
Хотя в некоторых конкретных случаях может быть правдой... всё зависит от ситуации и плана джоина... (см. предыдущий пост)

[ivas]

имхо 2 while select'a надежней)))
просто если в обоих таблицах скажем по 10 000 000 записей (inventTrans и т.п.) то join может не отработать никогда и при это сложить бд)

[petr]

Цитата:

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

имхо 2 while select'a надежней)))
просто если в обоих таблицах скажем по 10 000 000 записей (inventTrans и т.п.) то join может не отработать никогда и при это сложить бд)

Не забывайте про контекст задачи, исходно вопрос стоял про salesTable - salesLine, там не должно быть более 10 000-100 000 записей.

ИМХО, большая проблема этих таблиц - большое кол-во полей (плюс еще каждое гориз./верт. решение добавляет десяток другой. Так что прирост производительности должно дать задание необходимых полей для выборки (если это возможно)ю

[Logger]

Цитата:

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

Не забывайте про контекст задачи, исходно вопрос стоял про salesTable - salesLine, там не должно быть более 10 000-100 000 записей.

Ну это как сказать.
я знаю примеры когда в salesTable больше 700 тыс. записей (причем в одной компании)
SalesLine - десятки миллионов.

[ivas]

Цитата:

Не забывайте про контекст задачи, исходно вопрос стоял про salesTable - salesLine, там не должно быть более 10 000-100 000 записей.

хм... у нас
SalesTable 344114
SalesLine 383276

парулет назад в SalesLine было больше 2 000 000 записей вот вам и контекст...