Добрый день, очень нужна помощь опытных абаперов:)

Не могу вставить код т.к. нахожусь не на работе, но очень нужен совет, не могу придумать хорошего решения((

Суть в том, что есть 5 выборок из таблиц, результаты нужны все, т.е. если в первой найдены данные, а в других нет, эта строка тоже нужна.

Делаю первый select и left join второй выборки, тут все отлично, НО, 3 и 4 и 5 выборка зависит от 2 и 3 и 4 соответственно, то есть нужно сделать еще 3 left joina, но как я понял абап этого не позволяет((( (в смысле сделать 3-ий left join к 2-му и 4-ый к 3-му и 5-ый к 4-му )

Какой нашел выход
сделать один селект + left join сохранить во внутр таблицу
сделать один селект + left join + for all entires предыдущей выборки , сохранить в еще одну внутр таблицу
сделать один селект + left join + for all entires предыдущей выборки , сохранить в еще одну внутр таблицу

То есть по ключу смотрю есть ли еще к нему данные в другой таблицы (может увеличится от одной строки до хоть скольки)

В итоге имею 3 внутренних таблицы, по ним делаю 3 loop-а (для ускорения использую ASSIGN) и с помощью Append собираю 4 самую большую внутр таблицу по ключам...

И вот тут то все подвисает, в итоговой таблице данных около 230 тыс строк....

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

Подскажите пож-та направление как решить проблему со скоростью выполнения программы, если хоть кто нибудь понял меня)) наверное только самые опытные программисты поймут написанное))))

если правильно понял и тормозит абап, а не бд -
нужно внутр таблицы объявить, как минимум, сортированными,
а где возможно лучше хэшированными, ключ совпадает с ключом в бд;
внешний луп - безусловный по первой табл., внутренние будут иметь условия по ключам,
подсмотреть справку по оператору loop - в каких случаях табл. ключ игнорируется,
использовать into вместо assign

hugo788: не льстите ни сообществу ни себе. Сложного ничего в вашей задаче нет.
1) открываете транзакцию se30\sat, смотрите советы(кнопка "советы"\Tips&Triks) в части работы со внутренними таблицами и некоторыми алгоритмами (ветка Internal Tables-Simple Algorithms). Так же, рекомендую заострить внимание на использовании sorted и hashed tables.
2) используя те же se30 или sat, снимаете статистику, смотрите, что же именно у вас тормозит и пытаетесь бороться именно с проблемными местами
3) если выяснится, что тормозит обращение к базе: st05 в руки и снимать трассу уже в субд
3) так же, настоятельно советую выполнить статические проверки кода (код-инспектор\расшир.проверка программ). По результатам этой доп.проверки можно иногда увидеть что где-то забыли заполнить фильтр, и происходит выборка по пустому фильтру FOR ALL ENTRIES

Спасибо большое за советы!! завтра буду копаться в этом направлении, не хотел никому льстить, просто думал, что не поймут, что имел ввиду
FOR ALL ENTRIES - всегда проверял, что заполнены таблицы, в селекте все отрабатывает хорошо, проблема возникает с объединением внутренних таблиц

Если делать 3 loop на больших таблицах, то тут конечно без сортировки не обойтись. Плюс добавляем один простой прием: сортируем внутренние таблицы по полям, которые будут использоваться в условиях loop. Затем делаем read table <внутренняя таблица> transporting no fields binary search with key = ... И если sy-subrc = 0, то начинаем loop с необходимыми условиями, только делаем небольшое добавление starting at sy-tabix. В результате loop начинается не с первой записи в таблице, а с первой записи, которая попадает под условие (или хотя бы под часть условий), что позволяет существенно экономить время работы программы. Ну а выход из цикла делаем, как только встречаем первую запись, которая не удовлетворяет некоторым условиям цикла.

Какие хоть таблицы - Z или стандартные? Если стандартные, то какие?

Таблицы PA0001 HRP1001 и z

Спасибо всем за ответы, а особенно за этот



Делал без read table сразу loop

В итоге только исправив это, время уменьшилось с 4 минут до 20 секунд!

hugo788, поверьте , если изучите и начнете применять советы из тр-ций se30 (а предложенный Nick_Papkov как раз оттуда), много какие программы у вас смогут работать гораздо быстрее.

Если уж очень нужно 3 раза join'ить, то используйте Native SQL.

Плохой совет.
Как было уже сказано, советы из sm30 - это то что нужно

hugo788 Возможно если вы опишите задачу не на уровне "получить данных из трех селектов", а более детально, то может даже эти три селекта будут не нужны. Учитывая что это ABAP HR, может быть задачу вообще можно решить используя путь анализа. Судя по названиям таблиц, вы скорее всего ищете какие-то соединенные объекты к полям 1 инфо-типа.