SAP NetWeaver AS ABAP Rel ease 702, ©Copyri ght 2010 SAP AG. Al l ri ghts reserved.

ABAP Keyword Documentation → ABAP - Ref erence → Processing Internal Data → Internal Tables → Internal Tables - Overview →
Row-Based Administration Costs of Internal Tables
In addition to the basic memory requirement described in Memory requirement for deep data objects required to
administrate internal tables in table headers, additional memory is required to administrate each individual row, so
permitting optimized access to the individual rows. This internal administration of individual rows has two variants:
A table index administrates the logical order of table rows. The additional memory requirement is 6 bytes per
table row on average. Exception: If the logical order matches the physical order in the table body, no additional
memory is required for the index.
Hash administration allows table rows to be accessed by hashing the corresponding key components. The
additional memory requirement is 18 bytes per table row on average as long as the table is not accessed
using the DELETE or SORT statements. Following access of this type, an average of 30 bytes is required per
table row.
How a table row is administrated depends on the table category and any existing secondary table keys. The table
category determines the basic administration of the rows of an internal table (table index for index tables, hash
administration for hashed tables). Each additional secondary table key introduces additional row administration (table
index for sorted keys, hash administration for hashed keys).
Indexes are therefore created in the following cases:
As the primary table index of a standard table for managing the order arising from index operations. However,
the order in the index has no relation to the content of the table rows. The index is only for the optimization of
index accesses. Content searches cannot be optimized and always lead to a linear search of all table rows.
As the primary table index of a sorted table or as the secondary table index of a sorted secondary table of any
other table for managing the order of table rows in accordance with the sorted primary or secondary table key.
The order of table rows is determined by the view of the table rows defined by the sorted table keys. This
defines an order for the rows of the table that can be used for optimized access by the binary search.
Hash administrations are created in the following cases:
For the primary table key of a hash table or for a secondary hash key of any other table. They do not permit
index access. They can only be used for optimized access with a fully specified table key.
If secondary table keys are used, additional memory costs may be incurred.
An internal table with at least one ambiguous sorted secondary key needs an additional 8 bytes per table row
for the basic costs of administrating possible duplicates. These additional basic costs are incurred only once
and not for each table key.
Additional memory costs are incurred if a secondary key needs to be updated following a change to the
content of the internal table. Again, this costs a few bytes per table row but varies greatly depending on the
number of changes made.
Examples
A standard table with a secondary hash key that is exclusively filled with APPEND requires:
No additional memory for the primary index since the logical and physical orders are the same
18 bytes per row for the hash administration of the secondary key
Following an access using DELETE or SORT, the memory requirement per row jumps to 6 bytes for the
primary index and 30 bytes for the hash administration.
A sorted table with a secondary hash key and two non-unique sorted secondary keys requires:
6 bytes per row for the primary index
18 or 30 bytes per row for the hash administration of the secondary hash key
6 bytes per row and key for the sorted secondary key from the moment from which it is used
8 bytes per row because there is at least one non-unique sorted secondary key