Age: 41 Joined: 01 Feb 2008 Posts: 387 Location: Воронеж
Posted: Wed Nov 19, 2008 2:48 pm Post subject:
Могу ошибаться, но SINGLE выбирает 1 попавшуюся строку, а Up to 1 Rows выбирает все строки, если надо сортирует и дает самую верхнюю из выбранных. Соответственно времени потратиться больше. _________________ Hормальные люди делают вещи намного более безумные чем всё, что делают сумасшедшие (c) С.Лем
XXX_:), в том то и вопрос если не ошибаюсь, то перевод такой: 'Используйте Select Single только с полностью указанным в условии WHERE первичным ключом. Иначе используйте Select.. Up to 1 Rows'. Вот и интересно, почему составители этого гайда так полагают
According to SAP Performance course the SELECT UP TO 1 ROWS is faster than SELECT SINGLE because you are not using all the primary key fields.
Но рекомендую прочитать всю статью по ссылке, она маленькая. _________________ Hормальные люди делают вещи намного более безумные чем всё, что делают сумасшедшие (c) С.Лем
According to SAP Performance course the SELECT UP TO 1 ROWS is faster than SELECT SINGLE because you are not using all the primary key fields.
Это так Сап рекомендует, а в этой же статье ниже такой абзац:
Quote:
The System test result showed that the variant Single * takes less time than Up to 1 rows as there is an additional level for COUNT STOP KEY for SELECT ENDSELECT UP TO 1 ROWS.
Потестил в разработке, при запросах без указания последнего ключевого поля - SELECT SINGLE * FROM BKPF получился побыстрее, а для BSEG наоборот немного медленнее чем UP TO 1 ROWS.
В общем мне по прежнему интересно, отчего и почему
UPD. Теперь понятно почему в SQL Quick Checklist есть такой совет - потому что Сап рекомендует. Но почему Сап рекомендует именно так?
Age: 41 Joined: 01 Feb 2008 Posts: 387 Location: Воронеж
Posted: Wed Nov 19, 2008 4:45 pm Post subject:
Ну я вообще не пользуюсь select...endselect.
А почему... ну я еще такого уровня мастерства не достиг пока еще не сенсей... Можно конечно книженцию по SQL достать, но блин работы много...
ЗЫ: мне тоже интересно. _________________ Hормальные люди делают вещи намного более безумные чем всё, что делают сумасшедшие (c) С.Лем
Ну я вообще не пользуюсь select...endselect.
А почему... ну я еще такого уровня мастерства не достиг пока еще не сенсей... Можно конечно книженцию по SQL достать, но блин работы много...
ЗЫ: мне тоже интересно.
а у меня работа временно кончилась, вот и маюсь самосовершенствованием
Age: 46 Joined: 05 Nov 2007 Posts: 725 Location: КраснАдар
Posted: Wed Nov 19, 2008 4:56 pm Post subject:
Сейчас еще vga и Удава дождемся - они в этом деле - доки (если мне память не изменяет по темам на форуме) . Тогда уж все усовершенствуемся
ЗЫ Я в этом деле слабоват - в основном везет на пользовательские интерфейсы, бизнес-объекты и расширения всякие... Отчетов, как в ритейле, пока не приходилось рисовать
Age: 48 Joined: 25 Jan 2008 Posts: 580 Location: Москва
Posted: Wed Nov 19, 2008 7:35 pm Post subject:
Планы запросов абсолютно одинаковы.
Различия проявляются, если в ..UP TO 1 ROWS вставить ORDER BY - тогда добавляется внуттренняя сортировка - тогда этот запрос тормозит...при первом запуске
На самом деле практически без разницы, какой из этих методов применять - основные "тормоза" как правило появляются в основной выборке на большом количестве записей роли не играет
Armann wrote:
Теперь понятно почему в SQL Quick Checklist есть такой совет - потому что Сап рекомендует. Но почему Сап рекомендует именно так?
Исключительно для обеспечения предсказуемости результата (есть ORDER BY) и читаемости кода _________________ С уважением,
Удав.
я обратил внимание что планы запросов одинаковы, но смутила разница во времени выполнения. Я ее списал на некие внутренние саповские механизмы
спасибо!
Age: 47 Joined: 14 Nov 2008 Posts: 300 Location: Russia
Posted: Wed Nov 19, 2008 10:57 pm Post subject:
Code:
SELECT mseg~mblnr mseg~mjahr mseg~zeile mseg~bwart mseg~xauto
mseg~matnr mseg~werks mseg~lgort mseg~insmk mseg~shkzg
mseg~dmbtr mseg~bwtar mseg~menge mseg~bustm mkpf~budat
INTO TABLE lt_mseg
FROM mseg JOIN mkpf ON mkpf~mblnr = mseg~mblnr AND
mkpf~mjahr = mseg~mjahr
WHERE mseg~matnr IN s_matnr
AND mseg~werks IN s_werks
AND mseg~lgort IN s_lgort
AND mseg~sobkz = ' '
AND mseg~smbln = ' '
AND mkpf~budat IN r_date
AND NOT EXISTS ( SELECT * FROM *mseg WHERE smbln = mseg~mblnr
AND sjahr = mseg~mjahr
AND smblp = mseg~zeile ).
Известно, что при больших объемах данных, вложенные запросы существенно замедляют быстродействие основного. В приведенной выше выборке вложенный запрос отсекает сторнированные позиции д-тов движений материалов. При большом числе выбираемых позиций (>1000000) данная конструкция в плане быстродействия оказалась более предпочтительней, чем обычный запрос, с последующим отсечением сторно в цикле по полученным записям. Поскольку в позиции прямого документа в таблице MSEG нет ссылки на сторнирующий, то в цикле по lt_mseg исключение сторно приходится делать единичной выборкой из MSEG (SELECT SINGLE ...) и при положительном ее результате (sy-subrc = 0) - удаление позиции из вн. таблицы. Единичная выборка в цикле (даже по ключу) и переиндексация lt_mseg при удалении из нее записи оказались неприемлемыми (дамп по таймауту). Вот такой вот частный случай.
P.S. В свое время постил это дело на сапборде... _________________ ABAP/4 You
Age: 47 Joined: 14 Nov 2008 Posts: 300 Location: Russia
Posted: Wed Nov 19, 2008 11:20 pm Post subject:
Использование вспомогательных вн. таблиц с оператором READ ... BINARY SEARCH.
Необходимое и достаточное условие: устраивающий объем оперативной памяти, выделенной пользователю на сервере приложений (отсутствие дампа по переполнению).
В приведенном выше посте мы получили вн. таблицу lt_mseg с позициями д-тов движений материалов. Как оптимальнее добавить краткие наименования ЕИ материала (в эту же или итоговую таблицу)? Перед основным запросом делаем ряд доп. выборок, в нашем случае, например:
Code:
* Единицы измерения
SELECT mara~matnr t006a~mseh3 INTO TABLE gt_meins FROM mara
JOIN t006a ON mara~meins = t006a~msehi
WHERE mara~matnr IN s_matnr
AND t006a~spras = sy-langu ORDER BY mara~matnr.
Затем, в цикле по lt_mseg вместо SELECT SINGLE ... мы пользуемся оператором READ TABLE gt_meins WITH KEY matnr = <fs_mseg>-matnr BINARY SEARCH (используется LOOP AT lt_mseg ASSIGNING <fs_mseg>). Т.о. быстродействие цикла можно увеличить на 10-15%, поскольку в течение несколькомиллионных итераций мы обращаемся не к серверу БД, а уже исключительно к серверу приложений.
Примечание: для корректной работы BINARY SEARCH вн. таблица (в нашем случае - gt_meins) должна быть отсортирована по ключу, который используем в операторе READ (см. help). _________________ ABAP/4 You
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
All product names are trademarks of their respective companies. SAPNET.RU websites are in no way affiliated with SAP AG. SAP, SAP R/3, R/3 software, mySAP, ABAP, BAPI, xApps, SAP NetWeaver and any other are registered trademarks of SAP AG. Every effort is made to ensure content integrity. Use information on this site at your own risk.
если не ошибаюсь, то перевод такой: 'Используйте Select Single только с полностью указанным в условии WHERE первичным ключом. Иначе используйте Select.. Up to 1 Rows'. Вот и интересно, почему составители этого гайда так полагают
пока еще не сенсей... 
