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

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


Ошибаетесь, см выше

Я тоже понимаю, что речь идет об использовании внутренних таблиц для буферизации. Конечно же сам пользуюсь этими приёмами! Но это никак не противоречит моим утверждениям, т.к. это приходится делать для лечения саповских же "геморроев". И рекомендации САПы имеют те же корни.

Не-не-не, немного путаете. Сапа умеет буферизовать указанные таблицы на стороне сервера приложений (см. технические свойства таблицы) - обычно это справочники, например T001. В случае простой выборки из такой таблицы данные во возможности возьмутся из буфера в сервере приложений и запрос до БД не дойдет, что собственно и ускоряет дело. А в случае запроса с джоинами придется лезть в БД, тут уж куда деваться - и вся эта буферизация оказывается побоку

Я понимаю для чего существуют буферизованные таблицы. Но мы же кажется говорим об оптимизации запросов при помощи внутренних таблиц вообще и "FOR ALL ENTRIES" в частности ?!
В общем, этот вопрос нужно рассматривать на конкретных задачах. Иначе дискуссия бессмысленна. За сим её и прекращаю!

золотые слова

Часто бывает делема между
FOR ALL ENTRIES
LOOP
READ TABLE
ENDLOOP
и
LOOP
SELECT SINGLE
ENDLOOP.

Понятно, что такие конструкции надо в принципе избегать, но если деваться некуда? То что будет эффективнее?

"ABAP-код: инспектор" (тр. SCI или SE38-Программа-Проверить-Код инспектор) за первый вариант.

Предпочтительнее FOR ALL ENTRIES, т.к. SAP еще оптимизирует его. Один Select разбивает на несколько реальных запросов к БД, но за один такой запрос может обработаться несколько записей из внутренней таблицы. Т.о. сокращается общее число, длина и время на интерпретацию запросов к базе данных в сравнении с Select в цикле.

Я почему-то думал, что FOR ALL ENTRIES сервер приложений представялет как LOOP SELECT SINGLE ENDLOOP, ну или примерно так. Рад, что ошибался. К сожалению не понимаю, как читать результат трассировки((

Посмотрите в плане запроса:
- for all entries: в Explain увидите, что в условии выбора несколько значений через IN на одну операцию
- select single in loop: по одному условию на каждую операцию

Сделал пример (надуманный, конечно, но для наглядности подходит) : сначала данные из LIKP выбираются, потом из LIPS по FOR ALL ENTRIES IN LIKP. Затем цикл по LIKP и select single из lips

Одна из операций REOPEN для for all entries


Для выбора в цикле:


Вот примерно разница...

Но последовательность операций примерно одинаковая будет в обоих случаях:

Только для "for all entries" их меньше будет, поэтому можно и так сказать:

SQL, но не его Open-реализация

Насколько я понимаю, то реализация SQL для обращения к кластерным таблицам недотягивает даже до Open SQL. Это я про JOIN.

смотрите ноту 881083, там есть пояснения к FOR ALL ENTRIES - количеству обрабатываемых записей
в BC490 ABAP Perfomance Tuning есть про трассировку и многое другое

Мнение внутренние таблицы и FOR ALL ENTRIES абсолютное зло не разделяю. Во всем хороша умеренность. Да и от задачи зависит.

Большой опыт оптимизации чужих программ показывает война JOIN c FOR ALL ENTRIES не главное.

1. Передается пустая внутренняя таблица в FOR ALL ENTRIES. Самая популярная ошибка.
2. Выборка идет не по индексам или не по тем индексам. В системе разработке все хорошо. В продуктиве плохо.
3. select single в loop
3. Программист ленив и выбирает select *
4. Используется loop, а там можно read. Или некорректный read
5. Считываются данные, которые потом нигде не используются
...

FOR ALL ENTRIES не зло при правильном использовании, особенно если почитать вышеназванные ноты.
При интерпретации он превращается либо в UNION либо в IN() либо в OR(.. and...) OR(.. and...)
Причем количество параметров в IN, число "OR" и UNION настраивается(но не рекомендуется менять настройку = 5 из-за потенциально возможного неравномерного расхода памяти на СУБД). Можно также метять эти параметры для конкретного запроса.
%_HINTS ORACLE '&max_in_blocking_factor 100&'
%_HINTS ORACLE '&max_blocking_factor 20&'



У меня сложился следующий список типовых ошибок:
I. Выбор данных из БД

1. Наличие дублирующих выборок данных.

2. Наличие неключевых выборок, выборок без использования индексов, выборок создающих большую нагрузку на БД.

3. Использование выборок в циклах.

4. Использование FOR ALL ENTRIES без проверки на пустоту внутренней таблицы.

5. Использование FOR ALL ENTRIES для большого числа одинаковых записей(без предварительного определения уникальных записей).

6. Конструкции SELECT … ENDSELECT, если это не обосновано.

7. Выбор всех полей без ограничения (SELECT *) (кроме небольших таблиц из 4-5 полей).

II. Обработка внутренних таблиц

1. Вложенные циклы, если есть возможность заменить один из них на READ.

2. LOOP … WHERE … для несортированных таблиц.

3. COLLECT для обычных (не сортированных или хеш-таблиц).

4. Некорректное использование конструкций LOOP … AT NEW, AT END OF.

5. Использование SORT+DELETE ADJACENT DUPLICATES вместо цикла со вставкой в хеш-таблицу.

6. Подсчет промежуточных сумм с использованием вложенных циклов, вместо использования промежуточных хеш-таблиц.

7. Использование READ без TABLE KEY или BINARY SEARCH, если есть такая возможность.

8. Проверка на пустоту HEDERELINE вместо тела таблицы.

9. Использование HEADERLINE.

10. Чрезмерное использование MODIFY, MODIFY …INDEX вместо использования FIELD-SYMBOLS.

11. Необоснованное использование глобальных данных (т.к. в отличие от локальных переменных они остаются в памяти все время выполнения программы).