Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Processing Internal Data →  Internal Tables →  Internal Tables - Overview 

Selection of Table Category

The category of table used in each individual case depends on the type of individual row access that is used most often on the table. These rules are made suitably relative to tables with secondary keys.

  • Standard Tables
    This category of table is appropriate when the individual entries can be addressed using the index. Access by the index is the fastest possible access to table entries. You should fill standard tables by appending lines using APPEND and implement the other accesses using an index specification (INDEX addition of the respective statements). Since the cost of accesses to standard tables using the primary key increases linearly with the number of table entries, this type of access should only be used on standard tables if the filling of the table can be separated from the rest of the processing. If a standard table is sorted after filling, the cost of a key access with a binary search (BINARY SEARCH) has a logarithmic relationship to the number of table entries.
  • Sorted Tables
    This category of table is appropriate if the table must be sorted from the time of creation. The filling of the table takes place by insertion using the INSERT statement and in accordance with the sort order defined by the primary table key. The cost of key accesses is related logarithmically to the number of table entries because a binary search is automatically carried out. Sorted tables are also particularly suited for partially sequential access in a LOOP loop, if the first part of the table key is specified in the WHERE condition.
  • Hashed Tables
    This category of table is suitable when key accesses are the central operation to be carried out on the table. Hashed tables cannot be accessed using a primary table index. However, the cost per key access is always constant and independent of the number of table entries. As with database tables, the key of hashed tables is always unique. Therefore hashed tables are suitable for creating internal tables that are similar to databases and can be used in a corresponding fashion.

Other versions: 7.31 | 7.40 | 7.54


Example

A table scarr_tab_down intended for index access should be sorted by key field in descending order. This can only be a standard table. If you want a table in ascending order, you can and should use a sorted table, in this case scarr_tab_up. If only key access is required, then a hash table like scarr_tab_key can be used.

DATA scarr_tab_down 
  TYPE STANDARD TABLE OF scarr 
       WITH NON-UNIQUE KEY carrid. 

DATA scarr_tab_up 
  TYPE SORTED TABLE OF scarr 
       WITH UNIQUE KEY carrid. 

DATA scarr_tab_key 
  TYPE HASHED TABLE OF scarr 
       WITH UNIQUE KEY carrid. 

SELECT * 
       FROM scarr 
       ORDER BY carrid DESCENDING 
       INTO TABLE @scarr_tab_down. 

scarr_tab_up = scarr_tab_down. 

scarr_tab_key = scarr_tab_up. 

cl_demo_output=>new( 
 )->write( scarr_tab_down[ 1 ] 
 )->write( scarr_tab_up[ 1 ] 
 )->write( scarr_tab_key[ carrid = 'UA' ] 
 )->display( ).