Как выбирать STANDARD, SORTED или HASHED TABLE по способу доступа, ключу, порядку и стоимости обслуживания.
4 мин чтения·База знаний
Ревизия 1Общие понятияЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Внутренняя таблица хранит строки в памяти программы. Выбирайте её тип по основному способу доступа: нужен ли индекс, важен ли порядок строк, будет ли поиск идти по полному или частичному ключу и должны ли ключи быть уникальными.
Есть индекс вставки. Доступ по индексу естественен; поиск по свободному ключу обычно просматривает строки последовательно.
Последовательная обработка, добавление строк, сохранение входного порядка или небольшой набор без частого поиска по ключу.
SORTED TABLE
Строки поддерживают порядок ключа. Ключ может быть уникальным или неуникальным; доступ возможен по полному ключу и подходящему начальному фрагменту ключа.
Нужны упорядоченный обход и повторные выборки по полному или ведущему фрагменту ключа.
HASHED TABLE
Доступ выполняется по полному уникальному ключу; первичного индекса нет.
Главная операция - точечный поиск по стабильному уникальному ключу, а индексный порядок строк не нужен.
Документация SAP описывает поиск по ключу для стандартной таблицы как линейный, для сортированной - как логарифмический, а хешированный доступ - как не зависящий от числа строк при обычной оценке алгоритма. Это ориентир по категории доступа, а не гарантия времени конкретной программы: на результат влияют размер строк, операции изменения, вторичные ключи и фактический профиль вызовов.
Перед объявлением типа выпишите реальные операции над набором:
Строки обычно обходятся все подряд или по очереди добавляются? Это аргумент в пользу STANDARD TABLE.
Часто читаются группы по начальным полям ключа и затем нужен упорядоченный обход? Проверьте, подходит ли SORTED TABLE и соответствует ли порядок полей ключа этим запросам.
Часто читается ровно одна строка по всем полям стабильного ключа, а порядок не нужен? Рассмотрите HASHED TABLE.
Нужны несколько способов чтения? Сначала определите основной и измерьте второстепенные. Вторичный ключ может помочь, но требует памяти и дополнительных затрат при изменении данных.
Ключ задаёт семантику доступа и идентичности внутри конкретной таблицы. Для хешированной таблицы первичный ключ обязан быть уникальным. У сортированной таблицы уникальность выбирается явно. Стандартная таблица допускает повторяющиеся значения ключа. Если дубликаты являются ошибкой бизнес-данных, это нужно проверять как отдельное условие: категория таблицы сама по себе не объясняет, почему строка повторилась.
Не полагайтесь на неявный стандартный ключ для прикладного алгоритма. Укажите поля, которые реально идентифицируют строку в этом наборе. Для финансового примера ключом сверки могут быть компания, год, номер документа и позиция, но применимость такого состава зависит от источника и выбранного уровня данных.
До загрузки данных решите, что делать с повтором ключа: отклонять набор, сохранять несколько строк в таблице с неуникальным ключом или агрегировать по отдельно заданному правилу. Молчаливое перезаписывание строки может скрыть проблему качества. Тестируйте как минимум дубликат ключа, отсутствующую строку, изменение порядка входа и повторный запуск алгоритма.
Вторичный сортированный или хешированный ключ может улучшить дополнительный способ чтения, но у него есть память и стоимость обслуживания. SAP отдельно указывает, что обновление вторичного индекса может происходить при обращении к нему после изменений таблицы, поэтому изменение строк и последующий поиск тоже относятся к профилю нагрузки.
Не добавляйте ключ только потому, что он доступен в синтаксисе. Сначала зафиксируйте размер набора, долю чтений и изменений, поля поиска и порядок вывода. Затем сравните вариант без вторичного ключа и с ним на целевой версии ABAP и типичном объёме данных.
Внутренняя таблица живёт в памяти текущего процесса. Её уникальный ключ не заменяет ограничение базы данных, межзапусковую дедупликацию, блокировку, идемпотентность публикации или управление LUW. Табличная категория также не определяет валютную точность, правила округления и смысл суммы: эти контракты задаются отдельно.
Ссылки ведут на актуальную документацию ABAP Cloud. Классический ABAP, конкретный выпуск SAP и доступные языковые элементы нужно сверять по документации целевой системы. Пример объясняет модель данных; синтаксис и производительность в SAP runtime здесь не проверялись.
An internal table stores rows in the program's memory. Choose its category based on the main access pattern: whether an index is needed, row order matters, searches use a full or partial key, and keys must be unique.
Has an insertion index. Index access is natural; a free-key search usually scans rows sequentially.
Sequential processing, appending rows, preserving input order, or a small set without frequent key searches.
SORTED TABLE
Maintains rows in key order. The key can be unique or non-unique; access can use a full key or a suitable leading key fragment.
Ordered iteration and repeated reads by a full or leading key fragment are needed.
HASHED TABLE
Access uses the full unique key; there is no primary index.
Point lookups by a stable unique key dominate and index order is unnecessary.
SAP documentation describes key search for a standard table as linear, for a sorted table as logarithmic, and hashed access as independent of the number of rows under the usual algorithmic model. These are access-category guidelines, not runtime guarantees for a particular program: row size, changes, secondary keys, and the actual call profile matter.
Before declaring a type, list the real operations on the collection:
Are rows usually scanned sequentially or appended? That supports considering STANDARD TABLE.
Are groups frequently read by leading key fields, followed by ordered traversal? Check whether SORTED TABLE fits and whether key-field order matches those reads.
Is the common operation an exact lookup by every field of a stable key, with no ordering requirement? Consider HASHED TABLE.
Are several read patterns needed? Identify the primary one and measure the others. A secondary key may help, but costs memory and adds work when data changes.
A key defines access and identity within that table. A hashed table's primary key must be unique. A sorted table's uniqueness is chosen explicitly. A standard table permits duplicate key values. If duplicate business data is an error, check that as a separate condition: the table category alone does not explain why a row was repeated.
Do not rely on an implicit standard key for application logic. Name the fields that identify a row in this collection. In a financial reconciliation example, a key might contain company, year, document number, and line item, but its validity depends on the source and data grain.
Before loading data, decide how to handle a repeated key: reject the dataset, preserve multiple rows in a table with a non-unique key, or aggregate under a separately defined rule. Silent replacement can hide a data-quality problem. Test at least a duplicate key, a missing row, changed input order, and a repeated algorithm run.
A secondary sorted or hashed key may improve another access pattern, but it uses memory and incurs maintenance costs. SAP notes that a secondary index may be updated when it is accessed after table changes, so mutations followed by a lookup are part of the workload profile too.
Do not add a key only because the syntax supports it. First record dataset size, the share of reads and changes, lookup fields, and output ordering. Then compare options with and without a secondary key on the target ABAP release and representative data volumes.
An internal table exists in the current process's memory. Its unique key does not replace a database constraint, cross-run deduplication, locking, publication idempotency, or LUW management. The table category also does not define currency precision, rounding rules, or the meaning of an amount; those contracts are separate.
The links point to current ABAP Cloud documentation. Check classic ABAP, a particular SAP release, and available language elements against the target system's documentation. This article explains the data model; syntax and performance were not tested in an SAP runtime.