ARTICLE
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
.
Secondary table keys should not be used 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 the uniqueness of table entries is of absolute importance, it is
better to avoid using secondary hash keys.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved