Оптимизация запроса

Parazit

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

Выполняются у меня примерно одинаковое количество времени (повторял несколько раз - то один дольше, то другой).

Надеюсь, проверялось на большом объеме данных. Хорошо бы, если нет разницы, а то недавно пришлось переделать запросы на CORRESPONDING, опасался заметной потери производительности.

Кодер

Если посмотреть хелп на 4.0 то там сказано следующее:

Цитата:

INTO clause
.....
Performance:

3. You should only use the variant ... INTO CORRESPONDING
FIELDS ... with large volumes of data because otherwise the
time required to compare the field names in the name table
is too high.

Если я еще правильно понимаю английский, то: наоборот, используйте эту конструкцию, т.к. иначе будет много времени тратится на определение, куда же складывать.
Скорее всего, коллега Monarch попутал вариант, когда не перечисляются поля вообще (select * вместо select field1 .. fielddN ). Как раз этот вариант рассмотрен в SE30 - примеры производительности. И как раз там видно (что в версии 4.0, что в ERP2005), что использование CORRESPONDING FIELDS не оказывает существенного влияния на производительность.

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

Да нет. Там написано, что использовать конструкцию INTO CORRESPONDING
FIELDS целесообразно только с большими объемами данных.
Иначе время на compare the field names in the name table будет заметно по отношению ко времени самой экстракции данных.

vakito

Но на небольших объемах данных это время в абсолютном значении весьма мало для того, чтобы дать заментый эффект производительности.

Jelena

Из моего личного опыта в ECC 6.0 + SQL Server - разница между INTO и INTO CORRESPONDING FIELDS в простом запросе (как тут был приведен пример) ничтожно мала. Полагаю, что "страшилки" либо устарели, либо тут бОльшее значение имеют какие-то другие факторы - например, количество задействованных полей, а также есть ли JOIN.

trop

к примеру, в таких случаях я делаю так: определяется структура для выборки
с типизацией полей вида type table-field, затем в runtime по структуре
однократно формируется строка имён полей с алиасами (пишется и отлаживается за 10 мин)
и тогда не надо писать into corresponding, к тому же менять структуру, не меняя запрос - удобно
(подозреваю что удобство, а не производительность, и была причиной):
load-of-program / class_constructor:
w = class=>sql_fields( any = data_l alias = 'bsis~s,bkpf~k' ).
..
select (w) from bsis as s inner join bkpf as k on .. into table data_t where ...

на стороне as-db при использовании into corresponding fields, вероятно,
выборка производится вначале во внутренний буфер,
затем по строкам производится mapping, этот map-loop будет как-то заметен
при 30-50 тыс зап, к примеру, по 512 байт, или чтоб не гадать можно просто замерить

Jelena

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

однократно формируется строка имён полей с алиасами (пишется и отлаживается за 10 мин)
и тогда не надо писать into corresponding

Мне INTO CORRESPONDING в основном приходится использовать потому, что в таблице посредине всунуты поля, которые не имеют отношения к выборке (например, какие-нибудь индикаторы). Изменить порядок полей в таблице не всегда возможно и целесообразно (в основном речь идет о поддержке старых программ). По-моему, в этом случае такой вариант особо не спасет...

trop

да, но можно в конец доп поля добавлять

birds

Удав написал(а):

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

Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.

Ну как сказать...
Посмотрите план запроса

Code:

data: begin of gs_bkpf,
        bukrs type bkpf-bukrs,
        belnr type bkpf-belnr,
        gjahr type bkpf-gjahr,
        awkey type bkpf-awkey,
        awtyp type bkpf-awtyp,
      end of gs_bkpf,
      gt_bkpf like standard table of gs_bkpf.

parameters: p_bukrs type bkpf-bukrs,
                   p_gjahr type bkpf-gjahr.
select-options: so_belnr for gs_bkpf-belnr.

field-symbols: <fs_bkpf> like gs_bkpf.
start-of-selection.
  select *
  into correcponding fields of table gt_bkpf
  from bkpf
  where bukrs = p_bukrs
    and belnr in so_belnr
    and gjahr = p_gjahr.

  loop at gt_bkpf assigning <fs_bkpf>.
    ...
  endloop.

В этом примере можно использовать "select *", так как интерфейс с БД корректно формирует запрос и указывает в обращении к БД конкретные имена полей из gs_bkpf вместо "*". :wink:

а в каком случае тогда нельзя? точнее, чем этот случай лучше остальных. мне казалось "select *" замедляет работу программы

Besa

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

а в каком случае тогда нельзя? точнее, чем этот случай лучше остальных. мне казалось "select *" замедляет работу программы

Замедляет в том случае когда Вам надо например всего 5 полей, а вы объявляете gt_bkpf Like bkpf occurs 0 with header line и используете при выборке select *.

aar

Запрос производится из двух таблиц посредством JOIN. Связь между ними однозначно определяется по полю OBJNR. В обоих таблицах есть поля KOKRS, BUKRS. Будет ли выигрыш в скорости от указания значений KOKRS и BUKRS для каждой из таблиц в условии WHERE?

а)

Code:

SELECT *
  APPENDING CORRESPONDING FIELDS OF TABLE itab
  FROM a
  JOIN b
    ON a~objnr = b~objnr
  WHERE
    a~kokrs = p_kokrs AND
    a~bukrs = p_bukrs.

б)

Code:

SELECT *
  APPENDING CORRESPONDING FIELDS OF TABLE itab
  FROM a
  JOIN b
    ON a~objnr = b~objnr
  WHERE
    a~kokrs = p_kokrs AND
    a~bukrs = p_bukrs AND
    b~kokrs = p_kokrs AND
    b~bukrs = p_bukrs AND.

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

Телепаты улетели на юг

Что за таблицы, сколько записей, какие индексы ну и т.п. Посмотрите в ST05 и делов то.

Удав

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

Запрос производится из двух таблиц посредством JOIN. Связь между ними однозначно определяется по полю OBJNR. В обоих таблицах есть поля KOKRS, BUKRS. Будет ли выигрыш в скорости от указания значений KOKRS и BUKRS для каждой из таблиц в условии WHERE?

1.Нет, если в таблице и есть индекс по полю objnr.
2.Если в таблице b меньше записей, чем в a, то запрос ускорится, если есть индекс по objnr в таблице a

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

Оптимизация запроса

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