Ограничение на кол-во записей в ranges

slim

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

Обращения к БД по ST05 к этим таблицам не было.
Если еще сделать буферизацию на уровне программы, то за счет уменьшения количества чтений время будет намного меньше.

Как сделать буферизацию на уровне программы, и вообще что она из себя вообще представляет?

Удав

Code:

DATA: gt_t499s TYPE SORTED TABLE OF t499s WITH UNIQUE KEY werks stand. "Глобальная буферная таблица для справочника t499s

...
FORM get_t499s USING p_data type <строка основной таблицы>.
  DATA: ls_t499s type t499s.

  CLEAR ls_t499s.
  READ TABLE gt499s INTO ls_t499s WITH KEY werks = p_data-werks
                                                                    stand = p_data-stand.
  IF sy-subrc <> 0. "Если записи нет в буфере
    ls_t499s-werks = p_data-werks.
    ls_t499s-stand = p_data-stand.
    SELECT SINGLE ktext
    INTO ls_t499s-ktext
    FROM t499s
    WHERE werks = ls_t499-werks
      AND stand = ls_t499s-stand.

    INSERT ls_t499s INTO TABLE gt_t499s. "Добавляем в любом случае, даже если запись в t499s не найдена
  ENDIF.
  MOVE-CORRESPONDING ls_t499s TO p_data. 
ENDFORM.

...
"Основной цикл
  LOOP AT gt_data ASSIGNING <fs_data>.
...
    PERFORM get_t499s USING <fs_data>.
...
  ENDLOOP.

В результате выборка значений с помощью SELECT будет выполняться столько раз, сколько встретится уникальная комбинация WERKS и STAND.

darkvolk

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

В результате выборка значений с помощью SELECT будет выполняться столько раз, сколько встретится уникальная комбинация WERKS и STAND.

а чем такой вариант лучше чем предварительная выборка из t499s всех нужных значений одним селектом с for all entries из gt_data по нужным параметрам?

Rokhay

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

Code:

DATA: gt_t499s TYPE SORTED TABLE OF t499s WITH UNIQUE KEY werks stand. "Глобальная буферная таблица для справочника t499s

Если использовать hashed table, будет быстрее.

Parazit

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

А кто сказал, что будет 5000 чтений из БД для справочников?

Ну, если в range кладут 5000 EQ, то можно предположить, что и выборка будет того же порядка.
Впрочем ты прав, это только мое предположение. Тут может пролить свет только автор!

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

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

Прежде чем взять, пусть и с сервера приложений, запрос сначала надо интепретировать. А интерпретация, да еще в цикле - всегда долго.

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

для небуферизированных таблиц можно организовать буферизацию на уровне программы.
При этом количество select single будет равно количеству уникальных значений в справочниках. :wink:

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

Но есть один недостаток, ухудшается читабельность и модификабельность программы.

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

А вот соединение через left join больше, чем 3-5 таблиц может занять у интерпретатора запросов Oracle большее время, чем интерпретация большого количества простых запросов.

Это все таки зависит от количество записей выборки. Думаю, при 5000 всё таки JOIN быстрее будет.
К тому же slim ранее уже подтвердил это:

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

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

И потом, наверно это вопрос предпочтений. Я, например, больше доверяю ORACLE при работе с БД, а вот САПу нет!

Parazit

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

Как сделать буферизацию на уровне программы, и вообще что она из себя вообще представляет?

Удав привел хороший пример, можешь попробовать.
Только, в данном конкретном случае, с выборкой по вспомогательным таблицам и в JOINе нет проблем - всё четко по ключам. Разница, если и будет, то не принципиальная. Основная проблема заключается в сложных условиях выборки по таблицам ANLA и ANLZ из-за кучи RANGE, как я понимаю, весьма не пустых. Ради интереса можно попробовать убрать все JOIN, оставить только ANLA и ANLZ, и потестить на производительность.

Удав

Parazit написал:

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

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

Прежде чем взять, пусть и с сервера приложений, запрос сначала надо интепретировать. А интерпретация, да еще в цикле - всегда долго.

Я же привел тайминги

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

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

Я же привел тайминги

Сферические и в вакууме

Моя точка зрения сильно ближе к точки зрения Parazit'а.
Oracle я доверяю больше. И у него тоже есть буфер.

Join вида

Code:

FROM vbak
JOIN vbuk
ON vbak~vbeln  EQ vbuk~vbeln
JOIN vbap
ON vbak~vbeln  EQ vbap~vbeln
JOIN t001w
ON vbap~werks  EQ t001w~werks
JOIN t001k
ON t001w~bwkey EQ t001k~bwkey
JOIN t001
ON t001k~bukrs EQ t001~bukrs
JOIN vbup
ON vbap~vbeln  EQ vbup~vbeln     AND
vbap~posnr  EQ vbup~posnr
JOIN vbep
ON vbap~vbeln  EQ vbep~vbeln     AND
vbap~posnr  EQ vbep~posnr

с агрегатами - 381 935.

Будем железом мериться?

slim

Сравнил 2 кода первый работает около 16 сек, а второй около 7 минут, при том условии что в табличке out_tab более 40000 записей
Форма GET_VZOBJECT буферизация таблички VZOBJECT(В самой таблице установлено "Буферизация запрещена") сделана так как предложил Удав
Первый код

Code:

    REFRESH IT_VZOBJECT.
    LOOP AT OUT_TAB INTO O_TAB.
      CLEAR IT_VZOBJECT.
      IT_VZOBJECT-ADROBJNR = O_TAB-INTRENO.
      PERFORM GET_VZOBJECT USING IT_VZOBJECT.
      APPEND IT_VZOBJECT.
    ENDLOOP.

Второй код

Code:

SELECT A~ADRNR A~ADROBJNR INTO CORRESPONDING FIELDS OF TABLE IT_VZOBJECT FROM VZOBJECT AS A FOR ALL ENTRIES IN OUT_TAB
      WHERE A~ADROBJNR = OUT_TAB-INTRENO.

Думаю, что
В первую очередь: надо пользоваться JOIN.
Во вторую очередь:
1. Если таблица БД буферизована, то FOR ALL ENTRIES IN
2. Если таблица БД НЕ буферизована, то программной ее буферизацией и SELECT SINGLE

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

Ограничение на кол-во записей в ranges

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