Новый составной тип данных «Mesh» и эффективность его использования
Mesh – это составной тип данных, появившейся в ABAP 7.40, который состоит из компонентов и связей между ними.
Компонентами (узлами) mesh могут быть как внутренние таблицы, так и ссылки, указывающие на внутренние таблицы.
Оглавление
Пример использования с проверкой эффективности
Первый вариант (с использованием mesh)
Второй вариант (с использованием сортированных внутренних таблиц)
Третий вариант (с использованием хешированных внутренних таблиц)
Сравнение производительности программ
Определение
Mesh – это составной тип данных, появившейся в ABAP 7.40, который состоит из компонентов и связей между ними.
Компонентами (узлами) mesh могут быть как внутренние таблицы, так и ссылки, указывающие на внутренние таблицы. Например:
TYPES:
BEGIN OF MESH mesh,
node1 TYPE lty_t_tab1 ASSOCIATION to_node2 TO node2 ON id = id,
node2 TYPE lty_t_tab2,
END OF MESH mesh.
DATA(mesh) = VALUE mesh( ).
С помощью ключевого слова ASSOCIATION в mesh задаются отношения между узлами. Как и при соединении таблиц в SQL необходимо указать условие связи при помощи оператора ON.
Обращение к узлу mesh такое же, как и в обычных структурах. Например (из объявленного выше):
mesh-node1 = lt_data_node1.
Для определения пути используется оператор \ (обратный слеш). Данный оператор считывает ассоциации как из корневого узла так и корневому. Пример:
mesh-node1\to_node2[ … ].
В квадратных скобках указывается условие чтения строки. Если запись по указанным условиям отсутствует, то возникает исключение CX_SY_ITAB_LINE_NOT_FOUND.
Стоит также отметить, что оператор чтения ассоциации можно использовать любое количество раз, главное, чтобы была связь с исходным узлом.
mesh-node1\to_node2[ … ]\to_node3[ .. ]\...
Ограничения:
- имя ассоциации не должно превышать 30 символов;
- имя ассоциации может иметь только буквы, цифры и «_», а также не может начинаться с цифры;
- рекомендуется название ассоциации начинать с символа «_», а также в нем должно содержаться имя целевого узла (например, _to_node2).
Пример использования с проверкой эффективности
Постановка задачи
Необходимо получить данные о сотрудниках в системе:
ИТ0000: табельный номер, вид мероприятия;
ИТ0001: организационная единица, штатная должность, должность;
ИТ0002: ФИО сотрудника;
ИТ0105: ид пользователя.
Решение
В качестве примера были написаны три варианта программы. Первая с использованием mesh, вторая с использованием сортированных внутренних таблиц, третья с использование хеш таблиц. Также были произведены замеры времени для сравнения производительности каждого из вариантов.
В программе используется ЛБД PNPCE, для чтения записей инфотипов используется чтение узла GET peras. Все данные необходимых таблиц накапливаются в соответствующих атрибутах классов. Для первого варианта – это узлы mesh, для второго и третьего – соответствующая внутренняя таблица.
Первый вариант (с использованием mesh)
Объявляем типы и внутренние таблицы:
Для того чтобы объявить mesh нам потребуется:
1. Создать типы для каждого узла, причем, если используется STANDARD TABLE, то ключ также необходимо указать (TYPE STANDARD TABLE WITH DEFAULT KEY), Рис. 1:
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 3
Комментарий от
Илья Казначеев
| 28 февраля 2020, 11:17
Комментарий от
Илья Казначеев
| 28 февраля 2020, 11:21
Комментарий от
Виталий Глущенко
| 16 марта 2020, 20:01
На своих экспериментах не увидел выигрыша между mesh структурой и внутренними табличками. Как правило разница в производительности колебалась +/-7%, если повторять такой "join" несколько раз, то разница в производительности скатывается до +/-1-2%.
При этом заполнение, что внутренних структур, что mesh структуры требует одинакового времени.
Разочаровывало (1) отсутствие поддержки Open SQL, поэтому собирать mesh структуру надо ручками и то, что (2) чтение одной и той же записи из mesh структуры, во второй и последующие разы занимает столько же времени сколько и в первый раз. Спрашивается, а зачем тогда мы указываем связи между полями с детализацией до полей (я про ASSOCIATION). На каждую ASSOCIATION в запись в главной таблице можно было добавить либо индекс, либо сразу адрес, который заполнялся бы при первом обращении, а при изменении строки сбрасывался. Overhead по памяти был бы незначительный, а скорость выросла. И последнее из явных разочарований (3), связи между таблицами только через = и and, а если у меня несколько таблиц с датой начала/датой окончания, то ASSOCIATION по такому ключу я уже не соберу, понятно.