Всем доброго дня!
Собственно, сабж.
В зависимости от каких критериев нужно располагать таблицы в селекте?
По кол-ву ключевых полей в условии, по кол-ву полей в условии, по ожидаемому кол-ву выбранных записей, по общему кол-ву записей в таблице, и т.п.
Для упрощения возьмем ситуацию, когда все таблицы соединяются в INNER JOIN по ключевым полям, а в условии есть ограничения для каждой таблицы.

иногда оптимизатор самостоятельно определяет первичную таблицу,
вероятно без разницы

Т.е. оптимизировать SELECT с JOIN-ми вручную смысла не имеет, мы просто пишем таблицы в любом порядке, независимо от того, по каким ключам они связаны и по каким полям есть ограничения? Как-то подозрительно всё просто... Думал есть свобода для творчества, ведь если тот же самый запрос делать через несколько отдельных выборок, то их последовательность играет очень важную роль.

вероятно лучше писать в том порядке в каком
предполагается выборка, для читаемости.
оптимизатор сравнивает статистики подходящих индексов
и выбирает менее затратный путь.
такое происходит на oracle, для него же
можно указать хинт ordered чтобы в порядке запроса или
хинт первой таблицы leading( jointab1 ),
и в st05 убедиться, что работает.

Присоединюсь к коллегам:
1. В случае oracle оптимизатор сам вибирает порядок джойна, но можно при помощи перечисленных troy хинтов этим управлять
2. По поводу ручного управления несколько эмпирических наблюдений.

Обычно, если в джойне существенное число таблиц, можно разделить их на три группы:
1. Очень большие таблицы, которые содержат основной объем данных и тормозят при выборке
2. Таблицы поменьше (всякие справочники значений)
а. Таблицы, которые никак не помогают фильтровать выборку из больших таблиц (типичный пример - названия к кодам, например названия заводов). Их, чтобы не путать оптимизатор Oracle лучше вообще убрать из селекта с join, выбрать отдельным селектом и дальше итоговую таблицу собирать в памяти при помощи loop + read table
б. Таблицы, которые оказывают влияние на выборку из больших таблиц. Вот тут надо сравнить, что обладает бОльшей селективностью: условия where к большой таблице или требование join с подмножеством маленькой и в зависимости от этого ставить на первое место либо большую таблицу, либо маленькую.

Как-то так, надеюсь не очень путанно объяснил.

Спасибо за разъяснения. С одной стороны, хорошо - не придется сидеть корпеть над динамическим селектом ~100 строк (не думаю что я лучше чем Oracle сделаю), с другой стороны, быстрее его заставить работать уже не получится, это была последняя соломинка.

Ммм... может стоит что-то упростить? Разбить селект на два, например. Создать индексы, чтобы выборка быстрее работала...
Испытываю горечь, когда приходится отлаживать чужие отчеты. Натыкаешься на большой селект - sy-subrc = 4. И все - следующие 30 минут выясняешь, в какой таблице, чего не хватает.

Там прелесть в том, что он динамический.

ну а кол-во таблиц в from хотябы какой порядок имеет - 10, 100?
статистику никак не собрать по наиболее долгоиграющим из получающихся запросов? И тогда уж оптимизировать только под конкретное подмнжество из них.

Таблиц не много, зато некоторые по несколько раз под разными псевдонимами ))
Оптимизировано уже все что можно. Индексы все на месте, с обработкой данных тоже все нормуль.
Оставалась не тронутой только структура самого SELECTа, а ее оптимизировать, как обсудили выше, смысла нет.
Апгрейдить надо заказчика, чтобы не было таких "простыней".

как написал LKU,
если в join тяжёлые таблицы, то лучше разделить запрос на несколько,
это ускорит выполнение, несмотря на увеличение результатов отдельных выборок

В данном случае ключевая проблема - FOR ALL ENTRIES. Любой JOIN будет лучше этого.
По поводу "прелестей" - "Сложно программисту - легко пользователю!". Мораль - программист не должен облегчать себе работу в ущерб качеству программы.

И это правильно! Программы пишут не для того, чтобы программисту было легче, а для того, чтобы пользователю было легче.
Испытываю горечь, когда натыкаюсь на раздельные выборки во внутренние таблицы, а потом кучу гов#окода, в котором черт ногу сломит. Что особо печально, такие проги практически не оптимизируются. Еще печальней встречать в форуме вопросы типа "как получить сумму в Select". Представьте себя на операционном столе, а молодой хирург спрашивает коллег: "А кто-нибудь знает, как вырезать аппендикс?".
Проблема в том, что к SQL относятся как к простому ведру, типа "сначала начерпаю из колодца, потом разберусь". А это мощнейший язык, придуманный умнейшими людьми. Я бы к SAP вообще не подпускал людей без знания SQL. Пусть сначала "на трупах" поучатся.

p.s.
Извините, накипело.
Разумеется не всегда можно нормально использовать SQL, ибо кластерные таблицы. Но это уже вынужденные меры, а не принципиальная позиция.

Да ну. Во-первых, FOR ALL ENTRIES зачастую лучше JOINов, если таблиц >2. Во-вторых, в некоторых случаях это единственный возможный вариант.

В целом согласен, но применительно к конкретному вопросу - не в тему. На работу пользователя способ реализации никак в моем случае не повлияет. Что касается облегчения работы - динамический селект как раз был сделан с целью улучшить качество кода (хотя качество - понятие относительное, конечно). А в части реализации он ну никак не проще отдельных выборок и подпрограмм.

Какому пользователю?
Вот перестал работать отчет. Консультант приходит, и начинает жаловаться, что запись не попадает в итоговую выборку. И говорит - "должна попадать". Кто будет разбирать чужой JOIN c 10 таблицами? А если данные программа читает порционно - достаточно 10 минут в отладке поймать sy-subrc = 4 и сообщить таблицу консультанту. Пусть уже сам разбирается, какого документа не хватает или почему бизнес-процесс пошел не так, как планировалось.
Разумеется, "куча гов#кода" - это уже другая крайность.