Ни разу не встречал FOR ALL ENTRIES лучше JOINов. Более того, во всех конкретных спорных случаях я выигрывал. Разумеется, за счет грамотного построения запроса и индексов.
Про единственный возможный вариант я уже упомянул. Это уже камни в сапу кидать надо.


В конкретном случае пользователь сильно теряет в производительности программы из-за FOR ALL ENTRIES.

Вот-вот, а поддержке с таким отношением приходится потом разгребать проблему раза в три дольше. И что характерно - пользователю от этого не легче, у него отчет работает неправильно и ему глубоко фиолетово насколько там красиво написано. Проблема в том, что ваша крайность 'только sql!' на практике ничуть не лучше противоположной крайности 'сначала выгребем все данные, потом разберемся' - в поддержке геморройно и то и другое, хоть и по разным причинам. Истина как всегда - сами знаете где

P.S. Слыхал о таком крайнем случае мегаSQLщика - в его программе шел первым делом оператор EXEC, где он на чистейшем Oracle SQL фигачил всю требуемую логику программы - выборку, обработку данных и etc. Собственно абапом пользовался только в случаях крайней необходимости - вывести данные, нарисовать отчетик.

Я сталкиваюсь все время как раз с обратным, приходится разгребать кучу abap-кода с внутренними таблицами. Он же (код) обычно и является источником ошибок. И времени на разгребание уходит раз в 10 больше, чем если бы это был SQL. В крайних степенях я говорю лишь потому, что наблюдаю вокруг SQL-безграмотность в крайней степени.
В защиту EXEC я ничего не говорил, однако, вероятно, большинству абаперов есть чему поучиться у это мегаSQL-щика.
p.s.
Вообще странно обсуждать необходимость изучения языка баз данных при том, что работать с ними приходится каждый день.
Одно могу сказать точно, т.к. испытал это на себе. После решения нескольких "сложных" задач на чистом SQL мозги несколько выпрямляются, а мышление становится гибче - вот такой вот парадокс!
p.p.s.
"Сложных" написал в кавычках потому, что поначалу они казались вообще неразрешимыми. А когда мозги выпрямились, оказались банальными.

А вы пример приведите думаю не мне одному будет интересно.
Плюс если напоговорить, то представляю ваш ужас когда вы столкнетесь c ORM например BOPF( EHS, TM ) где вообще слой БД укрыт от разработчика.

Вы не поверите, но я как раз приветствую подход, когда слой БД укрыт от разработчика. Пусть лучше грамотный программист типизирует задачи доступа к данным и разработает хорошие прикладные инструменты для этого. Чем каждый будет там "палками мешать, да ведром черпать". Хороший и понятный пример - 1С Бухгалтерия.
Примеры задач SQL, честно говоря уже не помню, т.к. было в конце 90-х (с тех пор только сап). Общей задачей тогда было построить БД бух. учета и сформировать все отчеты на SQL (аналоги стандартных отчетов 1С). Особенно запомнилась задача построения отчета с нарастающим итогом, причем одним запросом. Мышление, воспитанное на Foxpro, поначалу отказывалось ее решать, почему-то жутко не хватало понятия "номер записи", что в SQL отсутствует как чуждый элемент. Так что рекомендую эту маленькую головоломку.

p.s.
Я отнюдь не считаю себя профи в SQL и свои познания оцениваю чуть выше начального уровня. Тем более мне странно наблюдать такое единодушное неприятие SQL вместо того, чтобы хотя бы освоить элементарные вещи - самим же будет проще.

На мой взгляд, "неприятие" SQL у программистов объяснимо не только ленью:
1. Долгое время БД так позиционировались на рынке, что использовать их всерьез не возникало вообще никакого желания: оракл и прочий ынтерпрайз стоит немеряно денег, всякие mysql'и весьма бедны по функционалу. Этой сейчас только постгрес достаточно развился.
2. "А скрипач точно нужен?" Может язык общего назначения справился бы с назначением SQL? Особенно в части хранимок.
3. СУБД даже не пытаются ответить на вопрос: "Что если сервер БД (железка) перестанет справляться с потоком запросов на запись?".

Вообще получается 2 варианта: либо использовать примитивный SQL, с которым справится большинство СУБД, либо продаться в рабство ораклу и надеяться на всю катушку использовать его функциональность. Естественно многие выбирают первый вариант.

Я солидарен с Armann: всему свое время и место.
1) никакого непринятия к SQL нет. В текущей реализации архитектуры SAP упор делается на OpenSQL. Его синтаксис и возможности гораздо беднее нативных SQL. Но так и архитектура другая. Для текущей архитектуры - самое оно.
2) большие SQL запросы с большим количеством JOIN? да ради бога, пока все работает как надо и решение прозрачно (оба условия должны выполняться, оба)
3) native SQL - только тогда когда нужно. Его использование сразу же вырубает часть плюшек архитектуры (различные буферизации и прочее-прочее-прочее)

еще раз: каждому инструменту свое время и место. Нельзя с помощью одного запроса OpenSQL получить, к примеру, связку док.FI-док.движения MM, при необходимости идти от документа FI (т.к. связь в BKPF-AWKEY в виде НомерГод движ.материала). Можно сделать через native(Exec\endExec), но не нужно, т.к. не для того его делали. Зато только с native можно сделать выборку из др. субд, через линк.

PS: ждите переход на хану, в койей и будет раздолье sql на стороне сервера и работа с хранимками там же

Именно, всему время и место.
Принципиально не использовать джоины так же странно, как и принципиально не использовать выборку в промежуточные таблицы - инструмент нужно использовать исходя из ситуации и условий. И SQL - тоже инструмент, который надо знать абаперу, однако не нужно пытаться заткнуть им все дырки. Тем более что у САПа нет инструментов для нормальной работы с SQL - ну вот разве сможете вы 'покрутить' сложный селект в продуктиве, понять чего не хватает и что нужно поправить? Фигвам, SE16 в руки и вперед, разгребать

В плане SQL - может быть, хотя не факт. Однако этот пример приведен для демонстрации подхода: 'я на любом языке могу писать как на фортране'

в hana вроде можно тяжелые таблицы в озу распред. сурбд "поднимать" (in-memory db),
совсем новый abap..

Коллеги, сам был удивлен. Прошло мимо меня. Но имейте ввиду что ваше обсуждение FOR ALL ENTRIES некорректно. Прошу ознакомиться (там и на ноту ссылка есть).

Начиная с 7.0 сильно неоднозначно. Parazit неправ. Автору вопроса тоже очень советую прочитать что пишут на MSDN'е.

Суть вкратце: "Over the years we retired this way of executing FAE statements to a more efficient type of query. The type of query which in OSS note #652634 is named as ‘UNION ALL’ method. A slight change only, but..."

FOR ALL ENTRIES обычно по плану склеивает через OR, работает достаточно быстро и в 4.7

2 Пономарев Артем: кмк хрен редьки не слаще. Как я помню, основная трабла была в том, что табла из FOR ALL ENTRIES по дефолту бьется на части, для каждой из частей фактически выполняется отдельный запрос. Что на уровне субд (я буду говорить за оракл, т.к. с ним знаком) выливается : 1) возможно - в парсинг запроса, 2) открытие неявного курсора оракла 3) фетчинг данных 4) закрытие курсора 5) вытаскивание данных на апп.сервер
Мне что-то помнится, что UNION ALL вроде как все равно для каждой части пункты с 1 по 4 будет выполнять. Просто первоначальное объединение результатов будет происходить в субд.
Не?

ЗЫ: опять же.. очень доставляло наличие спец. нот для FOR ALL ENTRIES у DB2

Так нота только для MS SQL.
Насколько я увидел, для Oracle FOR ALL ENTRIES что в 4.7 (620), что в 6.05 (702) работает одинаково.

В терминах ST05:
1. PREPARE (если не используется HINT SUBSTITUTE_VALUES, то выполняется 1 раз)
2. OPEN/REOPEN
3. FETCH

Удав, это был ответ на позицию Parazit'а, которую я до этой ноты разделял на 100% (FAE не может быть быстрее JOIN'а). В данный момент это уже не так

Кодер, слаще. Тот оверхэд, который вы описали, не совсем верен для UNION. Хотя дело не в нем. Дело в том, что UNION ALL, в ряде случаев, сильно быстрее OR. Пример: как условие, OR может быть отброшено оптимизатором, что приведет к RANGE SKAN'у на пустом месте (увеличение IO операций). На больших объемах будет крайне заметно.

З.Ы.: Однако статья в блоге доставляет.
Начало

Окончание