Артём, ты правда думаешь, что скачать миллион записей из БД во внутреннюю таблицу, потом сформировать миллион UNION-запросов (ура, наконец то по индексам), послать их серверу БД и получить наконец в результате одну запись - это эффективнее, чем тупой JOIN между двумя таблицами, по миллиону записей каждая, и получить ту же самую единственную запись?!
Для меня ничего не изменилось, только FAE будет работать быстрее, чем раньше. Как был JOIN предпочтительней, так и остался!

imho:
иногда использую join с for all entries по индексным полям - выполняется за разумное время.
но join по большим таблицам иногда неэффективен, напр если 2 большие таблицы
или отсутствуют индексы.
например по текущ проекту - тормозит по ключевым полям join на vbfa (46млн зап),
ibinvalues (176млн) на ibsymbol (262тыс), join с табл ausp (750млн).
возможно это связано с текущей нагрузкой на субд,
но иногда две отдельные выборки с FAE и манипуляциями на стороне abap as
быстрее чем join в разы, возможно в этих случаях быстрее вернуть 200тыс записей (10-20Мб данных)
и затем обработать их, чем производить операции над множествами на стороне субд.

Хотелось бы взглянуть на исходный код с JOIN и FAE, если не затруднит.

(в data_t[] находится 1 строка)
если восстановить ibsymbol, то работает медленнее в несколько раз,
чем если добирать ibsymbol (см ниже)

В некоторых случаях да.
Я уже привел классический пример: использование условия OR для поля индекса отбрасывается оптимизатором с высокой долей вероятности. И вместо INDEX UNIQUE SCAN мы получим INDEX RANGE SCAN со всеми вытекающими.

Когда:
1. Записей в таблицах много
2. В результате запроса выбирается относительно небольшое их кол-во
3. В запросе используется условие OR для поля(ей) индекса
с высокой долей вероятности UNION ALL окажется быстрее JOIN'а несмотря на все оверхеды.

Такие дела

З.Ы.: trop, а планы можно посмотреть? Сами то запросы - тлен.

Жаль, потестить не на чем...
Однако условия не равны, во втором случае добавлено ограничение ibsymbol~atinn in atinn_r.

Для сравнения двух вариантов "пересечения двух множеств данных" нужно рассматривать чистый эксперимент, т.е. различаться должны только способы получения пересечения (JOIN и FAE), остальные условия должны быть равными.
Я тоже заметил, что в новом подходе FAE не будет строить неоптимизируемый "OR"-запрос (никаких других OR не рассматриваем), а значит использует индекс. При прочих равных JOIN тоже его использует, а значит в этом у FAE преимущества нет. Зато у FAE есть затраты: на передачу большого количества данных (п.1) на сервер приложений во внутреннюю таблицу, формирование и передачу в БД большого количества запросов, интерпретацию этих запросов сервером БД и их выполнение, и наконец передача результата (п.2) серверу приложений. У JOIN затраты только на небольшой запрос и выдачу небольшого результата.
При условии, что оба варианта используют одни и те же индексы, за счет чего FAE может быть эффективнее?

Вот смотри: нужно ограничить выборку набором значений поля, входящего в ключ. Как это будет записано с использованием DML выражения JOIN и в какой результирующий запрос к СУБД будет преобразовано?

З.Ы.: Дело не в использовании индекса как такового. А в том, что UNIQUE SCAN быстрее RANGE SCAN'а (UNION - это SET оператор, в отличие от условий (OR, GT, LT и далее по списку)). И при определенных вводных эта разница может вылиться в преимущество в общем времени выполнения FAE над JOIN (преимущество, при этом, может быть очень значительное).

Эээээ.. а с каких это пор JOIN стал относиться к DML?

Кодер, ну ок. Я опустил полную формулировку. Оператор раздела FROM DML оператора SELECT (и еще парочки, тоже DML ). Так более правильно.

З.Ы.: Кто скажет, что JOIN не относится к DML - пусть первый бросит в себя камень

atinn_r присутствует и в первом запросе тоже, упустил когда копировал

интересная тема. Надо будет потестировать FOR ALL ENTRIES и обычный способ, который я часто использую - объявление RANGE, забивания туда допустимого количества значений и выполнения одного SQL запроса с IN (в случае с простыми ключами, конечно).
Допустимое - это исходя из размера запроса и длины поля, чтобы СУБД могла схавать. (П.с. приходится Join не использовать, т.к. я в BW обычно получаю некий набор уже в виде внутренней таблицы).