Текущее время: Ср, июл 30 2025, 21:40

Часовой пояс: UTC + 3 часа


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


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Оптимизация запроса
СообщениеДобавлено: Пт, дек 12 2008, 17:10 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Пн, июн 25 2007, 17:37
Сообщения: 350
Пол: Мужской
Code:
  SELECT bsis~gjahr bsis~hkont bsis~belnr bsis~budat bsis~shkzg
         bsis~dmbtr bsis~zuonr bsis~augbl bsis~augdt bsis~xnegp
         bkpf~blart bkpf~stblg bkpf~bktxt bkpf~awtyp bkpf~awkey

  INTO CORRESPONDING FIELDS OF TABLE ifull
  FROM  ( bsis INNER JOIN bkpf ON bsis~bukrs = bkpf~bukrs AND
                                  bsis~gjahr = bkpf~gjahr AND
                                  bsis~belnr = bkpf~belnr )
  WHERE bsis~bukrs eq zz_bukrs AND
        bsis~hkont in zz_hkont AND
        bsis~zuonr in zz_ZUONR AND
        bsis~budat <= zz_DATE-high.


В данном запросике мы выбираем сальдо на начало, обороты.
Больше всего интересует вот эта строка "bsis~budat <= zz_DATE-high", что получается, данный отчет с каждым годом все медленее и медленее будет работать и в один прекрасный день сдохнет!!?


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:45 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Пн, дек 08 2008, 19:17
Сообщения: 92
Откуда: Москва
Пол: Мужской
Это точно. SAP вообще в таких случаях сальдо сохраняет в вспомогательную таблицу.

_________________
В смысле осмысления бессмысленности, смысл тоже имеет определенную осмысленность.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:47 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Пн, июн 25 2007, 17:37
Сообщения: 350
Пол: Мужской
VitalkaFS написал:
Это точно. SAP вообще в таких случаях сальдо сохраняет в вспомогательную таблицу.


Какую?


Последний раз редактировалось Valeriy Пт, дек 12 2008, 17:48, всего редактировалось 1 раз.

Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:48 
Ассистент
Ассистент

Зарегистрирован:
Ср, мар 05 2008, 15:30
Сообщения: 44
делал вызовом стандартной программы fs10n, работает быстро.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:52 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Пн, дек 08 2008, 19:17
Сообщения: 92
Откуда: Москва
Пол: Мужской
Наврал я совсем.
На самом деле когда позиция закрывается она стирается из BSIS, тобишь в этой таблице всегда актуальная расшифровка.
Так что, с производительностью все будет ок.
А вообще таблица итоговых записей GLT0 для FI-GL без новой главной книги и FAGLFLEXT для новой главно книги.

_________________
В смысле осмысления бессмысленности, смысл тоже имеет определенную осмысленность.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 19:17 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
Хотелось бы на всякий случай предупредить насчет использования zz_DATE-high. Судя по high, это SELECT-OPTION или RANGE какой-то. Если это SELECT-OPTION, то результат может получиться весьма неожиданным, если пользователь выберет не "Select ranges", а "Exclude ranges", например. Да и вообще HIGH может пустым оказаться, если, конечно, специально не делать проверки на экране.

Почему-то часто об этом забывают и рассчитывают, что пользователь сделает именно такой выбор, как ожидается. Assumption is mother of all screw-ups.

Кроме того, может стоит хотя бы GJAHR как-то разумно ограничить. :?

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Ср, дек 17 2008, 21:34 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
Если оптимизировать именно данный SELECT, то попробуйте избавиться от INTO CORRESPONDING FIELDS OF TABLE, это добавит %%30 производительности.
А вообще для сальдо и оборотов действительно есть отдельные таб.

_________________
Монарх - это серъезно (с) "Классик"


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Сб, дек 27 2008, 21:38 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Monarch написал(а):
Если оптимизировать именно данный SELECT, то попробуйте избавиться от INTO CORRESPONDING FIELDS OF TABLE, это добавит %%30 производительности.

А можно пример , при котором 30% выигрыша в производительности получается? :)

_________________
С уважением,
Удав.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вс, дек 28 2008, 16:40 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
Удав написал(а):
Monarch написал(а):
Если оптимизировать именно данный SELECT, то попробуйте избавиться от INTO CORRESPONDING FIELDS OF TABLE, это добавит %%30 производительности.

А можно пример , при котором 30% выигрыша в производительности получается? :)


Ну, специально сидеть и подбирать пример именно с 30% я, пожалуй, не буду :wink:
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.

_________________
Монарх - это серъезно (с) "Классик"


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вс, дек 28 2008, 17:10 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
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:
Гораздо большие тормоза в случае большого объема выбираемых данных будут в цикле по строкам таблицы с помощью loop .. into вместо loop .. assigning.

_________________
С уважением,
Удав.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Пн, дек 29 2008, 18:16 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Valeriy написал:
В данном запросике мы выбираем сальдо на начало, обороты.
Больше всего интересует вот эта строка "bsis~budat <= zz_DATE-high", что получается, данный отчет с каждым годом все медленее и медленее будет работать и в один прекрасный день сдохнет!!?

Строго говоря, в общем случае по одной таблице BSIS нельзя построить сальдо, нужно обязательно делать такой же запрос по BSAS, ибо BSIS + BSAS = BSEG.
Да, САПа для общих итогов по счетам в разрезе периодов (MONAT) использует таблицу GLT0, можно ей воспользоваться. Но если нужно получить сальдо в любом другом разрезе, например по полю ZUONR (не зря же оно у вас в селекте?!), или на дату не кратную месяцу, то придется каждый раз шерстить табличку, либо создать свою таблицу итогов в нужном разрезе, например, используя инструменты спецрегистров.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вт, дек 30 2008, 10:31 
Специалист
Специалист

Зарегистрирован:
Чт, окт 26 2006, 16:44
Сообщения: 149
Откуда: Москва
Monarch написал(а):
Ну, специально сидеть и подбирать пример именно с 30% я, пожалуй, не буду :wink:
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.


Расскажите, пожалуйста, откуда вы взяли, что эту форму запроса лучше избегать. Кусок из документации приведите или хоть как-то обоснуйте. Достаточно даже не на 30%, а 10%... Я лично заявляю, что никакой разницы в производительности не будет.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вт, дек 30 2008, 11:38 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
vakito написал(а):
Monarch написал(а):
Ну, специально сидеть и подбирать пример именно с 30% я, пожалуй, не буду :wink:
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.


Расскажите, пожалуйста, откуда вы взяли, что эту форму запроса лучше избегать. Кусок из документации приведите или хоть как-то обоснуйте. Достаточно даже не на 30%, а 10%... Я лично заявляю, что никакой разницы в производительности не будет.


Давно это было... :)
Скорей всего имеется ввиду, что лучше не использовать конструкцию CORRESPONDING, в стародавние времена попадалась мне саповская дока на эту тему, возможно еще с версии 4.0. С тех пор где то на подкорке и записано, что лучше использовать INTO TABLE, а не INTO CORRESPONDING FIELDS OF TABLE. Допускаю, что новые версии работают более оптимально.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вт, дек 30 2008, 12:27 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
Parazit написал:
vakito написал(а):
Расскажите, пожалуйста, откуда вы взяли, что эту форму запроса лучше избегать. Кусок из документации приведите или хоть как-то обоснуйте. Достаточно даже не на 30%, а 10%... Я лично заявляю, что никакой разницы в производительности не будет.


Давно это было... :)
Скорей всего имеется ввиду, что лучше не использовать конструкцию CORRESPONDING, в стародавние времена попадалась мне саповская дока на эту тему, возможно еще с версии 4.0. С тех пор где то на подкорке и записано, что лучше использовать INTO TABLE, а не INTO CORRESPONDING FIELDS OF TABLE. Допускаю, что новые версии работают более оптимально.


Все точно, и именно с версии 4.0 такой стереотип у меня :wink:
Vakito, а вы можете обосновать, что разницы в работе с/ без CORRESPONDING FIELDS OF совсем нет, т.е. производительность одинакова?

_________________
Монарх - это серъезно (с) "Классик"


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса  Тема решена
СообщениеДобавлено: Вт, дек 30 2008, 13:48 
Специалист
Специалист

Зарегистрирован:
Чт, окт 26 2006, 16:44
Сообщения: 149
Откуда: Москва
Monarch написал(а):
Все точно, и именно с версии 4.0 такой стереотип у меня :wink:
Vakito, а вы можете обосновать, что разницы в работе с/ без CORRESPONDING FIELDS OF совсем нет, т.е. производительность одинакова?

Два простейших запроса
Code:
DATA : BEGIN OF lt_ekko OCCURS 0,
         ebeln TYPE ekko-ebeln,
         bsart TYPE ekko-bsart,
         bsakz TYPE ekko-bsakz,
         bukrs TYPE ekko-bukrs,
         bstyp TYPE ekko-bstyp,
       END OF lt_ekko.

SELECT ebeln bsart bsakz bukrs bstyp
  FROM ekko
  INTO TABLE lt_ekko.

SELECT ebeln bukrs bstyp bsart bsakz
  FROM ekko
  INTO CORRESPONDING FIELDS OF TABLE lt_ekko.


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


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB