Вопрос
Извлекают ли такие методы, как describe_by_data
, get_ddic_field_list
, get_components
(из cl_abap_typedescr
и аналогичные) данные из базы данных, или они генерируются на сервере приложений?
Я посмотрел на эти классы, и все некоторые методы (которые, предположительно, заполняют кеш), по-видимому, извлекают данные нестандартными способами (METHOD ... BY KERNEL MODULE ...
), а другие извлекают данные из кеша. Мне интересно, как его вытаскивают, если он не кеширован.
Google тоже не дал мне конкретной информации по этой теме.
Некоторый контекст, если детали станут актуальными
Я занимался реализацией генерации динамических предложений выбора для некоторых общих классов (чтобы заменить звездочку для обработки на основе столбцов в S / 4HANA и, надеюсь, уменьшить нагрузку на БД).
Поскольку большинство этих классов извлекают данные в структуры типов словаря, я решил, что могу использовать описания типов служб типов времени выполнения (RTTS), чтобы получать списки полей и динамически генерировать предложение select на основе целевой структуры.
В большинстве случаев я могу обойти потерю производительности (если она есть), реализуя статические переменные (и обрабатывая их только один раз за сеанс), но я сталкивался с аналогичными случаями, когда статические переменные не подходили (обработка выполняется на неизвестных types), и мне пришлось отказаться от этой идеи, потому что я не был уверен, как это повлияет на пиковую производительность, если эти методы будут вызваны, скажем, 30 раз за сеанс.
Редактировать (просто кусок кода, чтобы избежать дальнейшей путаницы, которая приводит к снисходительным комментариям без содержания):
lo_struct ?= cl_abap_structdescr=>describe_by_data( header ).
ct_components = lo_struct->get_components( ).
"Loop through ct_components appending names to lv_select_clause
lv_select_clause = get_header_fields( is_target_structure = header ).
select single (lv_select_clause)
from rbkp
where gjahr = @iv_gjahr
and belnr = @iv_belnr
into corresponding fields of @header.
Что ж, четко обозначенная проблема - это половина решения. Если вы хотите динамически формировать целевую структуру для выбора в нее данных БД, это вполне возможно с помощью RTTS (не знаю, для чего вам нужны детали реализации RTTS). Просто перепишите свой вопрос и подробно опишите свою задачу и дайте свои фрагменты / работы / прогресс на данный момент.
Еще интереснее, если бы Вы также создавали предложение связывания / присоединения динамически. В вашем случае это просто выглядит так, как будто вы хотите выбрать НЕКОТОРЫЕ конкретные поля из ОДНОЙ таблицы. Я делал это несколько раз. Что касается деталей, извлекает ли rtts определение ddic из самой базы данных, НО вы не уверены, получите нужные поля таблиц DD02L или DD03L. Но в большинстве случаев вы можете доверять RTTS, получить компоненты, создать целевую структуру, затем таблицу, а затем использовать comptab для создания строки select-clause-string. Взгляните на structdescr-> GET_DDIC_FIELD_LIST.
Я рассмотрел динамически объединенные выборки, но, похоже, это больше проблем, и я хотел выяснить, стоит ли беспокоиться о скорости метода RTTS. С учетом сказанного, у меня возникла одна идея - использовать describe_by_name
(вместо describe_by_data ', передавая таблицу имен структур (вместо самих структур) и создавая на основе совпадений между именами таблиц БД и именами в целевых структурах. таблица должна быть указана в select) обязательное ручное сопоставление в 3-й таблице.Это сложно, но в конечном итоге достигает цели.
@icbytes Просто обновление привязки поля соединения. Я сделал один, но для вызова требуется большой набор параметров (для работы с неоднозначными именами полей таблиц db и глубоких структур). Использование такого метода очень ограничено. В качестве эксперимента я реализовал его в сложной выборке из больших таблиц, которая, по сути, получает целевую таблицу type data
, что позволяет использовать различные структуры целевой таблицы. Стоит отметить, что стоимость обработки (дополнительной, после выбора) в этом эксперименте довольно высока.
Я не могу быть уверен в последних версиях ABAP, но этот материал словаря ABAP (AKA «DDIC» для словаря данных) происходит из таблицы базы данных DDNTT и DDNTF (также называемые «nametab», а его элементы называются «объектами среды выполнения базы данных»), которые заполняются во время активации объектов DDIC (таблицы и т. д., Эти таблицы - DD02L, DD03L , как сказано в @icbytes и т. д.).
Когда они запрашиваются, они также передаются и сохраняются в памяти каждого сервера приложений. Эта память называется буфер nametab. Самые новые данные заменяют самые старые данные при заполнении буфера.
Понятия не имею о производительности, но нет сомнений в том, что ею можно пренебречь по сравнению с SELECT, который вы делаете сразу после этого.
Еще кое-что о RTTS, всегда используйте методы GET_ *, а не о CREATE_ *, потому что они быстрее (они ведут себя немного иначе, но, как правило, только опытные разработчики могут нуждаться в последних).
Если хотите, вы можете добавить еще один уровень памяти, но я думаю, этого не стоит делать (больше времени разработчика тратится + больше памяти потребляется по сравнению с отсутствием большого улучшения производительности).
Спасибо за ваш вклад. Прошу прощения, если я не совсем понял, но то, что я делаю, ЯВЛЯЮСЬ динамическим выбором, но тот, который использует RTTS для динамического формирования списка полей / столбцов (на основе целевой структуры) предложения select. Не могли бы вы пояснить, что заставило вас сказать, что я переписываю RTTS?