ABAP Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Internal Tables - Overview → Table Keys → Secondary Table Key
Using Secondary Keys
Notes on Using Secondary Table Keys
- The standard scenario for sensibly using secondary table keys relates to a very large internal table that is created in the memory and whose content is changed very infrequently. Costs for administrating the secondary keys are then only incurred when setting up the internal table.
- As a matter of principle, secondary hash keys should not have too many components, since otherwise the system has to deal with a high system load for the additional hash management. Sorted keys are preferable for secondary keys with a large number of components.
- For an index table with secondary keys, the primary index of the table is updated immediately when rows are inserted or deleted using a secondary key. Note deleting a row from a standard table using a secondary key cannot be optimized because the index entry to be deleted must be searched linearly.
- Secondary keys might be useful for small internal tables in some circumstances because they ensure unique table entries in relation to particular components. Primary keys do not allow this, especially in the case of standard tables.
- In the case of pure read access when ensuring unique table entries is not relevant, non-unique secondary keys are usually sufficient. Read access is almost as quick as for unique keys, while the update following a table modification is quicker and is performed using a lazy update.
- You should not use secondary table keys in the following situations:
- For small internal tables (less than 50 rows), the performance benefit for read accesses is by far outweighed by the increased storage and administration load.
- With tables that are subject to a large number of write accesses, the load incurred by updating the secondary keys outweighs the performance benefit for read accesses. With delayed updates and lazy updates in particular, the update load can actually occur during a read access, which is where the optimization was required.
- Unless you want to ensure the uniqueness of table entries, it is better to avoid using secondary hash keys.