База знаний

Новый составной тип данных «Mesh» и эффективность его использования

1438
3

Оглавление

Определение

Пример использования с проверкой эффективности

Постановка задачи

Решение

Первый вариант (с использованием 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:

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.

Комментарии:

Илья Казначеев (Рейтинг: 333) 11:17, 28 февраля 2020

Годная статья, ждем статью с разбором производительности хешированных таблиц там и там, и почему такая разница.

Илья Казначеев (Рейтинг: 333) 11:21, 28 февраля 2020

Заходите на огонек: t.me/sapabap

Виталий Глущенко (Рейтинг: 120) 20:01, 16 марта 2020

Спасибо за статью, но было бы неплохо увидеть исходник полностью, потому что полученные вами результаты замеров вызывают вопросы. Особенно рис. 11 и 12. Возможно неправильно понял, что с чем сравнивалось.
 
На своих экспериментах не увидел выигрыша между mesh структурой и внутренними табличками. Как правило разница в производительности колебалась +/-7%, если повторять такой "join" несколько раз, то разница в производительности скатывается до +/-1-2%.
При этом заполнение, что внутренних структур, что mesh структуры требует одинакового времени.
Разочаровывало (1) отсутствие поддержки Open SQL, поэтому собирать mesh структуру надо ручками и то, что (2) чтение одной и той же записи из mesh структуры, во второй и последующие разы занимает столько же времени сколько и в первый раз. Спрашивается, а зачем тогда мы указываем связи между полями с детализацией до полей (я про ASSOCIATION). На каждую ASSOCIATION в запись в главной таблице можно было добавить либо индекс, либо сразу адрес, который заполнялся бы при первом обращении, а при изменении строки сбрасывался. Overhead по памяти был бы незначительный, а скорость выросла. И последнее из явных разочарований (3), связи между таблицами только через = и and, а если у меня несколько таблиц с датой начала/датой окончания, то ASSOCIATION по такому ключу я уже не соберу, понятно.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»