If “HASHED is faster when there is more data” is your first thought when declaring an internal table, it is easy to overlook the behavior you actually need. The choice depends on whether the same ID may appear more than once, whether row positions matter, and whether records will be read in ID order. Start with the rules the data must obey, then match the table to the reads you will perform most often.
An internal table is data that an ABAP program works with in memory. This is not about changing indexes on database tables. The comparison here covers only primary keys and primary indexes in tables without secondary keys. The code is a fictional example using syntax within the scope of ABAP 7.51. It has not been executed or benchmarked in an actual SAP system.
1. Before inserting three rows, decide what to retain
Assume there are two fields: an ID and a display character. The intended insertion sequence is 1002/B, 1001/A, and 1002/C. B and C are two rows with different content, but the same ID. If ID is the key, they have a duplicate key; the complete rows are not identical. Make this distinction before deciding whether duplicates are allowed.
The primary key of a STANDARD TABLE is non-unique. If these rows are added one after another with APPEND, all three are retained in the sequence 1002/B → 1001/A → 1002/C. Inserting the row with ID 1001 later does not automatically move it to the first position. This is a natural fit for sequential reads or access by a specific row number. However, SORT and insertion at a specified position can change the order, so do not treat this table category as a guarantee that insertion order will remain unchanged forever.
A SORTED TABLE maintains ascending primary-key order. If ID is declared as a NON-UNIQUE KEY and all three rows are inserted, 1001 comes first, followed by the two rows with ID 1002. The diagram shows the two equal-ID rows as a group. An ID-only key does not express a business rule requiring B or C to come first. If a receipt sequence must also be maintained within each ID, decide separately how that sequence will be represented in the data and key design.
2. Allowing or rejecting duplicates changes the meaning of the table
A SORTED primary key can be UNIQUE or NON-UNIQUE, while a HASHED primary key must be UNIQUE. Changing a list that needs several records per ID to HASHED TABLE WITH UNIQUE KEY id therefore changes the requirements. Before treating a one-line declaration change as an optimization, check whether retaining multiple records with the same ID is actually required.
What happens if the HASHED example first inserts 1002/B and 1001/A, then attempts to insert 1002/C with a single-row INSERT ... INTO TABLE statement? Since ID 1002 already exists, the final row is not inserted and sy-subrc is set to 4. The existing B is not replaced with C either. The minimal example below saves the return value in a separate variable immediately after each insertion. It explains how to interpret the expected results; it is not a captured execution result.
TYPES: BEGIN OF ty_row,
id TYPE i,
label TYPE c LENGTH 1,
END OF ty_row.
DATA lt_by_id
TYPE HASHED TABLE OF ty_row
WITH UNIQUE KEY id.
INSERT VALUE #(
id = 1002 label = 'B' )
INTO TABLE lt_by_id.
DATA(rc1) = sy-subrc.
INSERT VALUE #(
id = 1001 label = 'A' )
INTO TABLE lt_by_id.
DATA(rc2) = sy-subrc.
INSERT VALUE #(
id = 1002 label = 'C' )
INTO TABLE lt_by_id.
DATA(rc3) = sy-subrc.The expected values according to the documentation are 0 for rc1 and rc2, and 4 for rc3. The final rows are 1002/B and 1001/A; this does not imply their display order. The program must decide whether a duplicate should be recorded in a separate list, treated as an error, or handled by an explicit update. This explanation is limited to the statements above, which insert one row at a time using the unique primary key and no secondary keys. Do not generalize the same return-value rule to inserting multiple rows at once or assigning data in other ways.
3. Separate finding a value from accessing a row number
STANDARD and SORTED tables have a primary index and can be accessed by row number. HASHED tables have no primary index. “Read the second row, then move to the next one” and “Find the one row with ID 1002” are different requirements. If you need the second item as displayed on a screen, first define the display order and the structure that represents it.
For a single-row read using the primary key, STANDARD uses a linear search, SORTED uses a binary search, and HASHED uses hash access. Simply changing the table category does not make every search condition faster in the same way. For partial-key access on SORTED tables, it matters whether the search starts with the leading key components. For hash access on HASHED tables, the complete key value matters. Here the key consists only of ID, so specifying ID supplies the complete key.
If the key contains both ID and a receipt sequence number, knowing only ID is different from knowing the entire composite key. Likewise, reading one row from a SORTED table with repeated IDs is different from looping through every record with the same ID. Stating whether you need one result or several helps avoid confusion when selecting a read statement.
A large amount of data does not automatically make HASHED the right answer. Consider insertion and update frequency, memory and administration costs, and the actual search conditions together. The three rows in this article illustrate the rules; they are not a benchmark showing speed differences. Secondary keys expand the options, but also require discussion of maintenance costs and the statements used to access them, so they are outside this article's scope.
4. Check a small example before changing the declaration
Describe the choice in one sentence. For “Keep all three records in insertion order and read the whole list,” consider STANDARD. For “Keep several records with the same ID while maintaining ID order,” consider NON-UNIQUE SORTED. For “Keep one row per ID and repeatedly look it up by the complete ID,” HASHED is a candidate. These are starting points: if sorting and row-number access are also required, UNIQUE SORTED may fit.
When checking this yourself, first insert the three rows and count them. Next, check how many rows have ID 1002, which display characters remain, and whether row-number access is part of the requirement. Then add cases for looking up a missing ID and inserting a duplicate ID again. Agree whether these expected results must remain unchanged when the table category changes, then verify syntax and behavior in the actual environment. This helps avoid changing the meaning of the data while trying to improve performance.