Здравствуйте.

Подскажите пожалуйста, какой из вариантов будет работать быстрее:

1. полностью выбирать данные из двух таблиц во внутренние таблицы, а потом с помощью LOOP идти по первой таблице и READ'ом считывать необходимые данные из второй

2. Сразу из второй таблицы выбирать только те данные, которые используются в первой таблице с помощью JOIN (в этом случае потом мне нужно будет все равно использовать LOOP по первой и READ по второй, но вторая таблица уже будет намного меньше по объему записей)?

3. Создать свою таблицу со структурой, содержащей необходимые поля из первой и второй таблиц, и с помощью JOIN выбрать нужные поля из обеих таблиц в свою таблицу (опять же потом мне нужно будет LOOP'ом бежать по этой таблице (такой алгоритм), но уже не нужно будет делать никакого READ).

Мне больше нравиться первый вариант, но только:

1. Выбрать не все данные, а нужные поля.

2. Из второй таблицы выбрать данные с помощью FOR ALL ENTRIES по первой таблице.

3. Таблицу по которой будет идти LOOP сделать SORTED, а таблицу по которой будет READ TABLE сделать HASHED.

Пробовал я так - время обработки увеличивается В РАЗЫ (если не использовать FOR ALL ENTRIES - секунд 10, а с ним - больше 30).

В чем выгода заменить один select c JOIN, на N select-ов с перекачкой по сети кучи ненужных данных?

Какие отчеты приходилось оптимизировать на предмет выпадения в дамп по таймауту, в большинстве своем использовали именно FOR ALL ENTRIES.

Предпочитаю, когда удается точно связать таблицы по ключу, использовать JOIN. Но не всегда это возможно.
Поэтому 3.

3. Однозначно. Т.к. именно на клиенте объем работы с данными будет минимален => минимально время исполнения.
З.Ы.: Кстати, FOR ALL ENTRIES на 4.6C под ORACLE работает кошмарно (возможно ваш случай). Чтобы добиться приличной скорости необходимо писать хинт.

В тр. SE80 -> Примеры производительности.
Смотреть не пробовали?

Продолжайте смотреть. Объемы данных ни о чем не говорят?

З.Ы.: Выборка данных далеко не самый ресурсо- и время- емкий процесс.

Для того чтобы правлильно оптимизировать отчет нужно знать как все работает:
1. обычный селект формирует на сервере приложений курсор и отправляет его на сервер бд (маску по которой будут выбираться данные) и в цикле делает фетч тоесть выбирает следующую запись удовлетворяющую условию курсора и отправляет ее на сервер приложений который уже обрабатывает ее потом просит еще потом опять фетч и тд (в практике естественно там организован буфер и пуляются ветаки наверно не единичными записями а по несколько штук, скорее всего, так точно не знаю)
2. селект инту табле, формирует на сервере приложений курсор и отправляет его на сервер бд, сервер бд порыхлому все выбирает (сам делает фетчи) и сформированные данные отправляет одним большим куском, нет траты времени на перестрелку данным между сервером приложений и бд, меньше засирается канал связи между ними, меньше зависимость от его пропускной способности, загруженности, задержки.
3. как работает вложенный селект додумаетесь сами.
4. форолентриз формирует кучу маленьких селектиков которые обрабатываются самостоятельно, дальше додумаетесь сами, естественно он быстрее вложенного селекта, если правильно додумались как они работают поймете почему.
5. вьюха(джоин) работает как селект только формируется хитрый курсор.
Из всего сказанного явствует что быстрее всего будет работать вьюха интутабле :0)

Однако для совсем крутой оптимизации нужно знать какое железо на сервере приложений, какое на сервере бд, какой канал между ними, какая средняя загрузка у них и каков резерв, и в соответствии с этим переносить основную массу работы на самое жирное устройство :0)

дальше..........

внутренние таблицы обрабатываются только на сервере приложений, и бывают трех основных типов стандартные сортированные и хешированные.
в стандартную таблицу быстрее всего добавляется запись, в сортированную и хешированную значительно дольше. Чтение медленнее всего рид читает из обычной таблицы и время чтение напрямую зависит от ее размера, потому как поиск записи идет брутфорсом. рид по сортированной таблице идет быстрее и зависимость от размера таблицы експоненциальная тоесть время чтения таблиц из 1000 и 2000 записей различается сильно, а время чтения таблиц из 1000000 и 2000000 различается незначительно, потому что поиск идет бинарисёрчем. Время чтения из хешированной таблицы абсолютно не зависит от ее размера.
Луп работает быстрее всего по сортедтабле, догадайтесь почему.
(но есть оговорка, это в том случае если выбирается значительный объем записей, если одна две то быстрее будет по хешедтабле)

Естественно все сказанное о внутренних таблицах правда если только поиск ведется по полям ключа.


Все дополняйте, исправляйте :0)


З.Ы. ох и гимморойное это дело - оптимизация :0)

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

Комментарии
1. Забыли важный аспект: far all entries увсегда работает как DISTINCT. Что не всегда приемлемо. Плюс описанные мною траблы на 4.6 + Oracle (заметно, естественно, только на больших объемах).
2. Read по стандартной таблице нифига не медленнее, чем по сортированной. Ибо запрос надо писать правильно (сиречь ORDER BY) и использовать доп. BINARY SEARCH в риде. Плюс, естесвенно, не INTO wa, а ASSIGNING <wa>.
3.
Неа. Разницы между JOIN и предопределенным JOIN (вьюха - это логический объект БД) не будет никакой.
4. В остальном - согласен.

Ну я же написал "5. вьюха(джоин)" :0)
А вся разница между ними, что в одном случае хитрый курсор формируется только на основании данных в АБАП коде, а во втором случаее лезется в словарь (маленьким селектиком) и условия соединения берутся оттуда. Это не имеет никакого значения, поскольку в скомпелированном коде все уже есть, а лезется в словарь только на этапе компиляции.

А вот про кластерные таблицы рассказать забыл.
Что она из себя представляет? Грубо ключ и приделанную к нему большую колбасу RAW. В словаре, для каждой таблицы входящей в кластер, лежат адреса (в этой колбасе) всех полей входящих в данную таблицу, проще говорить смещение от начала колбасы и размер поля. При всяких разных селектах эти данные берутся из словаря и добавляются с запрос (язык эскюэль позволяет так делать чтобы данные брались по смещениям и распихивались в разные переменные) кстати ограничение по вьюхам(джоинам) к кластерным таблицам связанно с тем что кампилятор тупо не может собрать запрос (курсор) в котором одновременно будут собираться данные по разным таблицам, а потом еще распихиваться по смещениям в переменные, поэтом просто посылает такого страждущего. А совсем забыл вся работа по "накладыванию маски на RAW-колбасу" осуществляется на сервере БД. О как :0)

А, а чтобы вообще всех поразить скоростью селектов поищите в интернете "Указания базе данных в ABAP Open SQL ".
Ну например указать компилятору в какой диалект эскюэля компилировать:
(Самому писать лень, прибегну к плагиату)
SELECT [...] FROM [...]
WHERE [...] GROUP BY [...] HAVING
ORDER BY [...]
%_HINTS <переключатель> '<текст>' <переключатель> '<текст>' [...].
# Фраза «%_HINTS» содержит список пар, состоящих из переключателя базы данных и текста указания.
# Переключатель является ключевым словом и может принимать одно из следующих значений:

ADABAS, AS400, DB2, DB6, INFORMIX, MSSQLNT, ORACLE

# В каждой системе используется указание с соответствующим переключателем. Другие указания игнорируются. Если указание оказывается пустым после выполнения операции подстановки, описанной ниже, или отсутствует вовсе (пробел), оно также игнорируется.
# Текст указания может быть либо литеральным символом ('...'), либо переменной. Если используется переменная, то SQL-оператор становится динамическим. В этом случае эффективность кэша SQL-операторов снижается.
# Для каждой базы данных возможно определить несколько указаний в одном операторе. Будут ли все они использоваться, и каким образом это произойдёт, зависит от базы данных.

Вот :0)

Только за такие козни, могут побить, ибо если перейдут на другую БД - может появиться гимморой как при "екзек эскюэле" (а в приведенном примере точно появится) :0)

Поправляюсь: уже подзабыл про директивы, щаз прочитал и осознал это :0)
Дело в том что именно в данном примере указываются типы БД и в зависимости от типа строчка с директивами, компилятор ищет директивы для текущего типа БД, остальные директивы просто проигнорируются, так что все пучком :0)

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

:0)

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