Привет,

с чего бы это select с указанием FOR ALL ENTRIES по сортированной таблице (причём сортированную по полям, указанным во WHERE, т. е. по к-рым идёт join на внутреннюю таблицу) отрабатывает гораздо медленнее, чем тот же select с FOR ALL ENTRIES по той же таблице, но несортированной?

Или там не join вовсе, и FOR ALL ENTRIES по-другому организован?..
Где можно почитать про такие технические подробности FOR ALL ENTRIES и про интерпретацию планов с указанием внутр. таблиц?

1. Время выпролнения запроса FOR ALL ENTRIES не зависит от сортировки таблицы значений для WHERE.
2. F1.
3. Текст и план выполнения запроса всегда можно посмотреть в ST05.

Воистину, ибо джойнить не с чем. Генерится довольно тупой код с перечислениями условий через OR. Если условий (то бишь записей внутр. таблицы) много, генерится несколько запросов.

Пономарев Артем,

смутило действительно большое различие времени выполнения по сортированной и несортированной табличке. F1 этого не объясняет...

Parazit,

Про join я, конечно, ересь написал. Т. е. согласно документации, последовательно выполняются операторы с подставленными значениями и объединяются. И вот тут-то и вопрос. Происходит, возможно, рекомпиляция планов, что на больших наборах может приводить к замедлению (сам боролся с подобным в Oracle).

В общем, придётся планы изучать...

Я потому и советовал ST05 посмотреть, что там этот "довольно тупой" текст запроса можно посмотреть. Т.е. увидеть, что сортировка ни при чем.
По поводу изменения плана запроса - тоже маловероятно. В этом смысле Oracle птица гордая, не пнешь - не полетит (либо сбор статистики, либо прямое указание оптимизатору запросов).
Так что разумного объяснения я не вижу.

А я вот вижу рациональное объяснение: расхождение возможно в случае если выполнялась сперва выборка по сортированной, а потом - по обычной таблице. Данные кэшируются на уровне того же оракла (раз Вы работали с ним, то про алгоритм LRU должны были слышать). Т.е., для чистоты эксперимента, имхо, следует несколько раз прогнать выборку по одному алгоритму и для измерения взять последние значения. Ну а потом повторить все тоже самое для второго. В случае если это не проясняет ситуацию, то надо ST05 в руки и просто просмотреть план запроса.

Приведите свой запрос, тогда хоть будет понятно, что за буферизация и индексы у таблицы

Вообще FOR ALL ENTRIES лучше не использовать. К этой конструкции приходится прибегать в крайних случаях, например, при обращении к кластерной таблице.

Parazit,

это сильное утверждение! Хотя, судя по реализации FOR ALL ENTRIES...
А что можете предложить на замену?

Или же "правильный" алгоритм: всё нужное закачивать во внутренние таблицы и задействовать loop/provide/read, не сочетая выборки из словарных и внутренних таблиц?
По-моему, это не всегда возможно...

Бывает так, что много быстрее сделать два отдельных селекта и потом соединить из по средствам loop + read table binary search.
Но это зависит от многих факторов, например какие таблицы, сколько записей, какие данные имеем для выборки, по каким полям и т.д.
Действительно, приведите Ваш запрос.

Тут такой подход - если для выборки требуется FOR ALL ENTRIES (или вообще любые внутренние таблицы), значит вы делаете что то неправильно, например:
- создали кластерную таблицу и теперь пытаетесь считать из нее данные;
- используете составные ключи в одном поле (типа BKPF-AWKEY);
- используете вычисляемые поля, типа GLT0-TSL01, GLT0-TSL02...
К сожалению, SAP уже во многом об этом "позаботилась" и мы вынуждены использовать внутренние таблицы.

На замену, в собственных разработках, могу предложить только правильную нормализацию данных и проблем с JOIN не будет.


Это как раз пример самого неправильного алгоритма. В идеале нужно обходиться совсем без внутренних таблиц. Например, если ваш отчет фактически должен содержать 3 записи с агрегированными суммами по некой аналитике, то идеальным будет запрос, возвращающий готовый результат. Простейший вариант, использующий SELECT и WRITE вполне удовлетворяет этому требованию. На крайняк можно хранить во внутр. таблице готовый результат, т.е. те самые 3 строки.
Понятно, что идеалы недостижимы, но они для того и существуют, чтобы к ним стремиться.

Не быть такому. Это странный идеал.

Разумеется не быть, САПа не даст. Данное утверждение касается только обращения с СУБД. Я исхожу из того, что SQL - очень мощный самодостаточный язык. По большей части внутренние таблицы используют из-за плохого понимания SQL (исключая вышеописанные случаи с класт. табл. и т.д.). Я сам прошел по этим граблям.

Да ладно, с вашим ли опытом быть таким категоричным?
Использование внутренних таблиц позволяет упростить запросы, а значит их проще отлаживать и оптимизировать.
Также нагрузка с сервера БД (который у нас один) переносится на сервера приложений (которых у нас много).
Сам САП так и рекомендует - запросы делать попроще, обработку данных по возможности переносить на сервер приложений - думаете это они с жиру бесятся?
Просто нужно меру во всем знать - деятели, которые читают весь bseg во внутреннюю таблицу также вредны, как и деятели, джоинящие десяток таблиц в запросе.
Понятно что есть случаи когда все проще и лучше сделать одним запросом - так на то голова и нужна, чтоб определить как в данном конкретном случае будет лучше. Главное не зацикливаться на какой то одной концепции

Согласен