Интересно, почему в R/3 применяется 3-х звенная архитектура клиент-сервер?

Насколько я понимаю, задача выбрать закупочные заказы, для которых выполняются условия:

1. Заказ создан определенным пользователем и/или имеет определенный номер
2. Есть хотя бы одна позиция с нужным заводом (EXISTS ... ekpo)
3. Есть запись о выходном документе (NAST):
- с видом выходного документа ZEDI
- сформированная в определенное время(?)
- со статусом "обработано" или
- со статусом "не обработано", если для документа не было любых(!) выходных документов со статусом "обработано" или
- со статусом "ошибка", если для документа не было любых(!) выходных документов со статусом "обработано" или "не обработано"

По-моему в постановке задачи или в реализации есть спорные моменты..Хотелось бы услышать, что в результате должно получиться.

По select:
1. Из NAST лучше выбирать с указанием KAPPL, чтобы было попадание в первичный индекс.
2. лучше разбить запрос на 2 части:
-выборка из EKKO, EKPO и NAST (без условий NOT EXIST). Цикл по выборке для удаления ненужных записей по NAST-VSTAT
-по полученным записям отдельные выборки из b027 и nach, v_user_name, lfa1.

Вот кстати да. Что-то я ушел в технические детали. Хотя запрос изначально вызывает вопросы к результирующему набору.

Практически согласен с Удавом, разве что выбирал бы сразу с NACH, V_USER_NAME, LFA1. А вот BO27 там в целом непонятно для чего. Можно выбросить, мне кажется.

Потому же, что и везде. Сервер приложений реализует: бизнес-логику, безопасный доступ, целостность данных, кеширование данных и т.д. И точно не должен быть помойкой ненужных данных. В идеале приложение должно получать только те данные, которые влияют на результат. Поэтому для оптимизации необходимо максимум усилий прилагать на уровне СУБД - конструкция запроса, индексация, нормализация... Перенос проблемы на сервер приложения я рассматриваю как "привязывание костылей", и стараюсь использовать его в крайних случаях.

Идеал практически недостижим
На практике нужно здраво распределять нагрузку между сервером БД и серверами приложений.
Как правило 3-х звенная архитектура легче масштабируется именно за счет серверов приложений, а не серверов БД.
Кроме этого, обработка данных в оперативной памяти быстрее, чем построение сложных выборок в БД.

Мне ближе позиция Parazitа. Я стараюсь максимально сузить выборки на стороне сервера БД. Но не в такой категоричной форме. Иначе она становится внутренне противоречивой.




В реальной же жизни бывают ситуации, когда и на клиенте данные приходится кэшировать, не то что на сервере приложений.

Абсолютно согласен, реальная жизнь вносит коррективы, я лишь говорю о приоритетах: 1 - СУБД, 2 - серв. пролож, 3 - клиент. А категоричен в такой степени потому, что наблюдаю сплошное нежелание большинства разработчиков хоть сколько-нибудь задуматься на 1-м уровне, сразу тянут во 2-й.

Так понятно, что во всем нужно соблюдать баланс: у нас например базисники регулярно выявляют "тяжелые" запросы к БД, которые написали разработчики.
И далеко не все запросы удается оптимизировать на 1-м уровне.
Оптимизация запросов на 1-м уровне зачастую требует глубоких знаний в конкретной СУБД, тогда как работа с внутренними таблицами интуитивно понятна практически любому программисту, знакомому с индексами.
upd:
Оптимизация программ кстати 3-х ступенчатая:
1. Оптимизация выполнения ABAP-кода
2. Оптимизация запросов к БД
3. Оптимизация памяти

Так и думал, что кто-нибудь скажет про недостижимость идеала. На то и идеалы, чтобы к ним стремиться! А если априори забивать на них, значит нет вектора, топтание на месте.
Насчет здравого распределения нагрузки полностью поддерживаю, именно об этом и говорю всё время.

Насчет быстроты обработки данных в оперативной памяти можно поспорить.
1. В затратах надо рассматривать всю цепочку от БД до клиента, а если из СУБД передали лишние данные - уже потеряли.
2. У сервера СУБД тоже есть оперативная память!
3. СУБД пишут ассы, полагаю они не задают в форумах вопросы об оптимизации запросов. А как напишет конкретный ABAP-ер - еще вопрос, если он не в состоянии оптимизировать выборку, он и в остальном накосячит.

p.s.
Кстати, как раз надысь задачу решали по оптимизации чужой разработки. Разумеется сначала решали чисто технически, не ломая алгоритмы. Индексы, кеширование, в ход пошла даже стандартная буферизация таблиц типа EKKO, EKPO и т.д. С трудом удалось достичь 2-х кратного ускорения. Однако пришлось анализировать алгоритм. Основным затратчиком оказался простой Loop в котором тупо перекладывались 9000 позиций заказа из одной вн. таблицы в другую. Вроде мелочь. Но когда выяснилось, что эта процедура выполняется для каждой позиции, да еще и 3 раза, то получилось 9000 * 9000 * 3 = 243000000. А из 9000 позиций реально нужна только одна. В общем после правки ускорилось раз в 10.
Вот и быстрая работа с оперативной памятью! Причем "писатель" сего даже после этого не поверил, что этот код такой затратный.

Пора резюмировать?

1. Степень и направления оптимизации выбираются исходя из текущих реалий конкретной ситуации и квалификации разработчика
2. Чем ниже опыт и квалификация специалиста - тем хуже итоговый результат (безотносительно того, запрос ли это к БД или алгоритм на ABAP)

Как-то так

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

В рамках оффтоп - сейчас изучаю книжку "Основы стоимостной оптимизации СУБД Oracle".
Автор как раз говорит о том, что о работе стоимостного оптимизатора Oracle с уверенностью ничего сказать нельзя
И приводит различные примеры (на основе 8, 9 и 10 версий Oracle), какие запросы работают хорошо, а какие - не очень.

ЗЫ: Думаю, что книжки хватит минимум на месяц

В рамках оффтопа же:
Удав, мне кажется, несколько некорректный вывод.
Перед тем, как оптимизатор построит план выполнения, - конечно нельзя. Можно только предполагать. Но не из-за непредсказуемости оптимизатора, а из-за нашей заведомой неполноты знаний (черный ящик же).
После того, как оптимизатор построил неэффективный план выполнения, обычно не так сложно разобраться откуда ветер дует. Более того, в подавляющем большинстве случаев виноватой окажется протухшая статистика. Хотя ввести оптимизатор в заблуждение можно, но обычно это запросы не из того разряда, что используются в SAP

Именно поэтому такие книги и пишутся. Я привел этот пример к тому, что разработчику легче научиться оптимизировать сложный ABAP-код(без черного ящика), а не сложный запрос к БД(с черным ящиком).

Если рядом есть грамотный базисник, то да. Хотел бы я посмотреть на проект, где разработчики имеют доступ к тонкой настройке СУБД

Например, запрос из этого топика

А лучше всего, когда разработчик хорошо разбирается как в работе с БД, так и в работе ABAP-кода

Ух, хорошо пооффтопили
Одно смущает, автор, похоже, исчез из обсуждения давным давно

А в целом, я бы не был так критичен к вопросу переноса нагрузки от/к СУБД - у каждой из Продуктивных систем свое "узкое горло" и когда начинаются проблемы с производительностью отчетов, приходится эту проблему искать. В нашей нынешней Продуктивной системе наибольшую нагрузку дает трафик между базой данных и апликейшенами. Вот в результате огромного множества тестов с разными вариантами обработки выбрали самый оптимальный для нашего случай подход - максимальный перенос обработки запроса в СУБД. И самый заумный "select .... inner join..." отрабатывает намного быстрее, чем любая из распределенных выборок.