FOR ALL ENTRIES vs RANGE

GeneralLao

Здравствуйте,
есть таблица:

Code:

DATA: BEGIN OF gt_pers_data OCCURS 0,
         pernr TYPE persno,
         fio LIKE p0001-ename,
""  Другие поля, штук 5.
   END OF gt_pers.
 

Надо по этой таблице сделать выборку селектом из БД.
Первый вариант так:

Code:

CHECK gt_pers[] IS NOT INITIAL.
SELECT * INTO TABLE gt_itab FROM zmy_table FOR AL ENTRIES IN gt_pers_data
                       WHERE pernr = gt_data-pernr .

Второй вариант:
собрать RANGE для поля pernr по таблице gt_data и использовать оператор WHERE pernr IN r_pernrs.

Столкнулся с ограничением, что если в рендже очень много строк, то SELECT не проходит, у FOR ALL ENTRIES есть такое ограничение?

LKU

Нет такого ограничения для FOR ALL ENTRIES, он бьет запрос на много маленьких и потом на уровне сервера приложений склеивает результаты

GeneralLao

Спасибо, а по производительности, примерно одинакого будет?

Через FOR AL ENTRIES мне больше нравится,
не надо лишний одноразовый RANGE заводить

LKU

По производительности в FAE при помощи хинта можно регулировать, сколько значений он объединит в одном запросе через OR.
Если вместо значения на сервере по умолчанию (5) ставить скажем 100, мне кажется никакой разницы не будет.
Только не забываем, что FAE неявно применяет distinct к выбранным значениям.

holocron

LKU написал:

По производительности в FAE при помощи хинта можно регулировать, сколько значений он объединит в одном запросе через OR.
Если вместо значения на сервере по умолчанию (5) ставить скажем 100, мне кажется никакой разницы не будет.
Только не забываем, что FAE неявно применяет distinct к выбранным значениям.

плюс как-то очень плохо FAE работает при выборке из join.

UKY

Вообще говорят, что FAE стараются сделать устаревшим: http://scn.sap.com/message/16853223#16853223.
Это, конечно, нереально, но двигаются в эту сторону.

Parazit

UKY написал(а):

Вообще говорят, что FAE стараются сделать устаревшим: http://scn.sap.com/message/16853223#16853223.
Это, конечно, нереально, но двигаются в эту сторону.

Судя по нововведениям, вполне реально, другое дело, что далеко не у всех новые версии SAP_BASIS.

Code:

REPORT demo_select_where_tab_exp.

CLASS demo DEFINITION.
  PUBLIC SECTION.
    CLASS-DATA carriers TYPE HASHED TABLE OF scarr
                  WITH UNIQUE KEY carrid
                  WITH NON-UNIQUE SORTED KEY name COMPONENTS carrname.
    CLASS-METHODS:
      class_constructor,
      main.
ENDCLASS.

CLASS demo IMPLEMENTATION.
  METHOD main.
    DATA name TYPE scarr-carrname VALUE 'United Airlines'.
    cl_demo_input=>request( CHANGING field = name ).

    SELECT carrid, connid, cityfrom, cityto
           FROM spfli
           WHERE carrid =
             @( VALUE spfli-carrid( carriers[ KEY name
                                              carrname = name ]-carrid
                                              OPTIONAL ) )
           INTO TABLE @DATA(result).

    cl_demo_output=>display( result ).
  ENDMETHOD.
  METHOD class_constructor.
    SELECT *
           FROM scarr
           INTO TABLE carriers.
  ENDMETHOD.

ENDCLASS.

START-OF-SELECTION.
  demo=>main( ).

GeneralLao

Ух. я уж на пенсию выйду когда у нас введут такие печеньки, и тем более FAE объявят устаревшим(

trop

в 740 SP08 для HANA появился неявный протокол Fast Data Access для быстрой передачи внутр. таблиц,
и вряд ли FAE куда-то денется

UKY

Parazit написал:

Судя по нововведениям, вполне реально, другое дело, что далеко не у всех новые версии SAP_BASIS.
SELECT carrid, connid, cityfrom, cityto
FROM spfli
WHERE carrid =
@( VALUE spfli-carrid( carriers[ KEY name
carrname = name ]-carrid
OPTIONAL ) )
INTO TABLE @DATA(result).
[/code]

Здесь просто выборка по 1 фильтрующему значению, а не по нескольким значениям одновременно, так что тут не замена FAE

А если можно будет подставлять несколько значений с сервера приложений, то это тот же FAE и получится - всё так и будет перегоняться с сервера приложений в СУБД.

P.S.: Сам жду с нетерпением, когда у нас ABAP 7.5 поставят

Правила форума

FOR ALL ENTRIES vs RANGE

Кто сейчас на конференции