Хм, это откуда такая инфа?

ST05 покажет fetch.

Угу. Логи для

и

идентичны...

Точно.

Обычно САПа делит одну выборку на несколько fetch. Так что не вся выборка хранится в памяти.

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

Вот-вот, посмотрите и старайтесь так не делать!

Вообще, в идеале, нужно программировать без внутренних таблиц. К сожалению это не всегда возможно, т.к. САПа изобрела их для решения проблем, которые сама же и породила. Те же кластерные таблицы, например.

В системе есть примеры производительности (SE38, затем по меню Среда-Примеры-Примеры производительности), в том числе и для описанного случая - так вот время выполнения отличается в разы.

Всегда старался следовать рекомендации SAP-а и работать через внутренние таблицы. После того как нарвался на ограничение размера таблицы (2 ГБ) с крупными таблицами работаю только через SELECT.....ENDSELECT. Кстати тестирование показало что в нашем случае снеижение производительности незначительно.

Ну мы вроде как не производительность обсуждали. Понятно что во втором случае быстрее.
Чтобы стало возможным программировать без внутренних таблиц - хотя бы поддержка SQL-92 требуется. Так что итабы - хороший костыль, заменяющий бедность синтаксиса open SQL.

Да синтаксис тут ни при чем, его вполне достаточно, чтобы оптимально программировать БД.
Это костыль, во-первых, для кластерных таблиц, т.к. их нельзя полноценно использовать с SQL (join, индексы...).
Во-вторых, из-за кривого построения структуры базы данных (неправильное построение ключей, полей...). Такой перл, как AWKEY, где содержимое состоит из нескольких полей, да еще и разных таблиц. Или периоды в GLT0, разнесенные на несколько полей одной записи, что превращает такую простую задачу для SQL, как агрегация за период в нетривиальную задачу на ABAP.

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

В ту пору, когда диски на ЕС ЭВМ были 29мБ, а дискеты на ПК 180-360кБ я только изучал СУБД и допускал точно такие же ошибки. Тогда же и понял, что такие подходы, в конечном счете, не экономят, а наоборот, расходуют память.
R/3 такая большая и имеет такое огромное количество таблиц не потому, что такая функциональная, а потому, что неверно спроектирована. Соблюдение правил реляций для реляционных БД толжно быть таким же четким, как 2x2=4.

Это еще что за зверь?
Может таки имелась в виду нормализация?

З.Ы.: Про достаточность синтаксиса open SQL - это вы зря. Кто работал с СУБД напрямую, не дадут соврать. Особенно в частности оптимального программирования БД. Если бы все было так просто, мы бы не увидели ни T-SQL, ни PL/SQL.

Вот когда вы организуете свою компанию по производству ПО, напишите продукт, который будет инсталирован на десятках тысяч клиентов в сотне стран и будете поддерживать все это хозяйство в работоспособном состоянии при помощи нескольких тысяч программистов в течение пары десятков лет, регулярно выпуская новые релизы, вот тогда мы и поговорим о "красоте" нормализованной базы данных.
P.S.
Я вовсе не против нормализации БД. Просто уже достали разговоры о том, как же все в SAP'е криво... Как говорится, не нравится, не ешь, никто не заставляет.

Хочу обратить внимание на то что R/3 это трёхзвенная архитектура.
И что проблему производительности на сервере приложений можно решать увеличением количества серверов приложений, то проблему производительности сервера БД так просто скорее всего не решается.
Это как аргумент в пользу внутренних таблиц.