ABAP: типы, внутренние таблицы и контракты данных

Тип ABAP задаёт форму данных, а тип внутренней таблицы дополнительно фиксирует модель доступа и свойства ключа. Это часть контракта метода: вызывающая сторона должна понимать, допускаются ли повторяющиеся ключевые значения, важен ли индекс и в каком порядке будут обрабатываться строки.

В документации SAP ABAP Cloud о ключах внутренних таблиц у каждой внутренней таблицы есть первичный ключ. У STANDARD TABLE он неуникальный и может быть пустым. SORTED TABLE поддерживает уникальный или неуникальный ключ и хранит строки в порядке ключа. HASHED TABLE требует уникальный хеш-ключ. Вторичные ключи дают дополнительные способы доступа, но требуют памяти и добавляют затраты при изменениях.

Как выбрать категорию#

Категория	Подходит, когда	Что проверить
`STANDARD TABLE`	Нужны индекс, последовательная обработка и накопление строк; повтор ключевых значений допустим	Чтение по первичному ключу при большом наборе может обходить строки линейно. Если читать нужно по ключу, предусмотрите сортировку с бинарным поиском или подходящий ключ и проверьте, что порядок и заполнение согласованы
`SORTED TABLE`	Набор должен сохранять порядок ключа; нужны чтения по ключу и последовательная обработка по начальной части ключа	Вставка поддерживает сортировку. Уникальность выбирается отдельно. Поля первичного ключа обычно нельзя менять при изменении содержимого строки
`HASHED TABLE`	Главная операция - поиск по полному уникальному ключу	Индекса строк нет, а ключ всегда уникален. Если возможны несколько строк на один выбранный ключ, такой ключ не подходит

Эти ориентиры основаны на официальном описании выбора категории таблицы. SAP описывает свойства и стоимость доступа; это не замер производительности конкретной программы.

Пример для финансового набора#

Предположим, программа получает синтетические строки документов для сверки. Один документ содержит несколько позиций, а при анализе требуется отобрать позиции по компании и финансовому году. Сначала разделите два понятия:

Бизнес-идентичность строки отвечает, какая позиция является той же записью в предметной модели. Например, в синтетическом примере это может быть сочетание компании, года, документа и номера позиции.
Ключ внутренней таблицы задаёт, как программа находит и упорядочивает строки в конкретном наборе данных. Он может повторять бизнес-идентичность, но может обслуживать другой частый доступ, например чтение по компании и году.

Если нужен исходный индексный порядок и строки только накапливаются, начните с STANDARD TABLE и не полагайтесь на неявный стандартный ключ. Если затем постоянно выбираются позиции по компании и году, сортированный ключ с этими полями в начале соответствует частичному последовательному чтению. Хешированный ключ уместен только для поиска строки по полному уникальному ключу; он не подходит для запроса, который должен вернуть несколько позиций одного документа.

Сумму храните вместе с валютой, а количество - вместе с единицей измерения. Это предметный контракт данных: тип числового поля сам по себе не сообщает, в какой валюте или единице интерпретировать значение. Не включайте сумму в ключ только ради ускорения чтения, если она не является частью идентичности строки.

Явно объявляйте ключи#

При объявлении через TYPES или DATA проверяйте, какой ключ задан явно и какой добавляется неявно. Для STANDARD TABLE пропуск ключа в объявлении DATA может добавить NON-UNIQUE DEFAULT KEY, который бывает пустым. В TYPES ключ DEFAULT KEY также может неожиданно оказаться пустым для стандартной таблицы. SAP советует явно указывать значимые компоненты; если первичный ключ для операций не нужен, можно осознанно задать EMPTY KEY. Для сортированных и хешированных таблиц первичный ключ должен быть указан явно.

Вторичный ключ может добавить путь чтения без изменения существующих обращений к таблице. Рассматривайте его как дополнительную структуру данных: выгода чтения должна оправдывать память и стоимость поддержания ключа при изменениях строк. Добавляйте его после того, как определили шаблоны доступа, а не по предположению, что больше ключей всегда лучше.

Проверка контракта перед реализацией#

Перед передачей внутренней таблицы через границу метода зафиксируйте:

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

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

Синтаксис и доступные API зависят от версии ABAP и модели разработки. Здесь описаны правила из документации ABAP Cloud, а не результат проверки компилятором или запуска SAP runtime; синтаксис нужно сверять с целевой системой.

Синтаксис и API различаются между классическим ABAP и ABAP Cloud. Код, допустимый в одной среде, может быть запрещён или непереносим в другой. Здесь нет заявления о запуске в ABAP runtime; точную грамматику сверяйте с документацией целевой версии.

Связанные материалы#

An ABAP type defines the shape of data. An internal-table type also fixes the access model and key properties. This is part of a method contract: callers should know whether repeated key values are allowed, whether an index matters, and in what order rows will be processed.

In SAP ABAP Cloud documentation on internal-table keys, every internal table has a primary key. A STANDARD TABLE key is non-unique and can be empty. A SORTED TABLE supports a unique or non-unique key and stores rows in key order. A HASHED TABLE requires a unique hash key. Secondary keys provide additional access paths, but require memory and add costs when rows change.

How to choose a category#

Category	Suitable when	What to check
`STANDARD TABLE`	You need an index, sequential processing, and row accumulation; duplicate key values are allowed	Primary-key reads on a large set may scan rows linearly. If key reads matter, consider sorting with binary search or a suitable key, and make sure the fill and ordering assumptions hold
`SORTED TABLE`	The set must stay in key order; reads by key and sequential processing by an initial key part are needed	Insertion maintains the order. Uniqueness is a separate choice. Primary key fields are generally read-only when changing the content of a row
`HASHED TABLE`	The main operation is lookup by a complete unique key	There is no row index and the key is always unique. If multiple rows can share the chosen key, it is unsuitable

These guidelines follow SAP's official description of table-category selection. SAP documents the properties and access costs; this is not a benchmark of a particular program.

Example for financial data#

Assume a program receives synthetic document rows for reconciliation. One document has multiple line items, and analysis needs to select items by company and fiscal year. First separate two concepts:

Business row identity answers which line item is the same record in the domain model. In a synthetic example, it might be the combination of company, year, document, and item number.
Internal-table key defines how the program finds and orders rows in this particular data set. It may match business identity, or serve another frequent access pattern, such as lookup by company and year.

If the original index order matters and rows are only accumulated, start with a STANDARD TABLE and do not rely on an implicit standard key. If the program repeatedly selects items by company and year, a sorted key with those fields at the beginning fits partial sequential reads. A hashed key is suitable only for looking up a row by the complete unique key; it does not fit a query that must return several items for one document.

Keep an amount with its currency and a quantity with its unit. This is a domain data contract: a numeric field alone does not say which currency or unit interprets its value. Do not include an amount in a key merely to speed up reads when it is not part of row identity.

Declare keys explicitly#

When declaring a table with TYPES or DATA, check which key is explicit and which is implicit. For a STANDARD TABLE, omitting the key in a DATA declaration can add NON-UNIQUE DEFAULT KEY, which may be empty. In TYPES, a DEFAULT KEY can also unexpectedly be empty for a standard table. SAP advises explicitly specifying meaningful components; when no primary key is needed for operations, EMPTY KEY is one deliberate option. Sorted and hashed tables require an explicit primary key.

A secondary key can add an access path without changing existing table accesses. Treat it as an additional data structure: the read benefit should justify memory use and the cost of maintaining the key when rows change. Add one after identifying access patterns, not on the assumption that more keys are always better.

Check the contract before implementation#

Before passing an internal table across a method boundary, state:

Which fields identify a domain row, and are duplicates allowed?
How will the data be read: by index, complete key, or initial part of a key?
Must row order be stable, or is ordering required only for a specific read?
Can the caller change primary-key fields?
Which values belong together: amount and currency, quantity and unit, date and its meaning?

These questions expose an ambiguous contract before the table choice becomes embedded in code. A secondary key cannot fix incorrect business identity, and a unique key requires that duplicates are truly invalid for this set.

Syntax and available APIs depend on the ABAP version and development model. This page describes rules from ABAP Cloud documentation; it does not report compiler validation or SAP runtime execution. Check syntax against the target system.