проясните плиз вопрос быстродействия: есть необходимость выгружать в несколько itab очень большие "связанные" наборы записей (SQL-выборка гдето на 100000 записей) с хитрой обработкой - т.е. по сути приходится реализовывать inner join на вн.таблицах.

Что быстрее - использовать sorted table with key для увязки, или standard table? В первом случае возникает вопрос - как вгружать данные в itab, т.к. ей требуется уже упорядоченный по key набор (иначе валится в дамп ILLEGAL_SORT_ORDER), а SQL-запрос не всегда позволяет использовать order by ?

Есть-ли прирост в скорости поиска в случае с sorted table, или оно и для standard wih key построит некий внутрениий "индекс" для быстрого поиска совпадений?

В таких случаях не бывает однозначного ответа. Лучше всего реализовать разные варианты и замерить.
Если по теории, то время чтения стандартной таблицы пропорционально количеству записей, сортированной таблицы - логарифму количества записей, хэшированной - от количества записей не зависит. Для стандартной таблицы также можно использовать бинарный поиск -
READ TABLE itab WITH KEY k1 = v1 ... kn = vn
BINARY SEARCH. Только для этого таблица должна быть отсортирована в порядке указанных в качестве ключа поиска полей. Также надо принять во внимание не только количество записей в таблице, но и количество чтений из нее. Понятно, что при большом количестве записей быстрее всего будет чтение из хэшированной таблицы. Однако, при добавлении записей в хэшированную таблицу тратится доп. время на расчет хэша. Поэтому если в таблице 1000000 записей, а прочитать ее потом будет надо 3 раза, то хэшированную таблицу использовать не надо.

У Вас классический случай, когда лучше всего применить метод "параллельных курсоров", описанный в примерах производительности.

спасибо, насчет курсоров посмотрю в RTFMe

пока реализовал с помощью двух одинаковых таблиц, одна standard, другая sorted - SQL-отбор идет в standard table, потом sort и перегрузка во вторую - а по ней уже розык через read table...with key

вродебы прирост есть, смущает только удвоенный расход ресурсов AS (по сути standard table какбы промежуточный буфер)

а нет ли способоа менять тип вн.таблицы? т.е. динамически объявить ее как standrd, заполнить данными из БД, отсортировать, а потом объявить как sorted?

Это не RTFM. Это в se80 - далее Среда->Примеры->Примеры производительности. Затем Internal Tables->Simple Algoritms->Joining internal tables.

А можно увидеть кусок кода в котором идет такая ошибка?
Так как звучит это очень странно - система сама вставляет записи в нужном порядке при заполнении внутр.табл.

Напр., следующий кусок работает на ура:

DATA: it_s TYPE SORTED TABLE OF bkpf
WITH NON-UNIQUE KEY blart budat.

SELECT * FROM bkpf INTO TABLE it_s WHERE bukrs = '2400'
AND gjahr = '2005'.

А зачем перегружать в sorted table?
READ TABLE itab WITH KEY k1 = v1 ... kn = vn BINARY SEARCH по стандартной таблице это тоже самое что и
READ TABLE itab WITH KEY k1 = v1 ... kn = vn по сортированной.

Sorted table однозначно быстрее, конечно при условии выборки по ключу.

Это APPEND валит в дамп, а вот INSERT не валит.

нда, загадочный язык этот абап - два оператора делают одно и тоже, а результат разный