‎2005 Nov 02 5:21 PM
What is SAP's recommendation to Developers on using the two types of Internal Tables? Which one is mostly used?
‎2005 Nov 02 5:28 PM
Hi!
If you have only full key access, use hashed table.
If you also have partial key access (e.g. loop where), use sorted table.
Mostly used? Standard table...
Hash and sort algorithm cost a little bit in creation - if you add line by line and just make one read (for every line) later, than you have a lot of overhead. Then standard table, one sort and read with binary search is faster.
When you make table fills (select into table) and have a lot of accesses (on a hugh table), then hashed should be in his best.
Regards,
Christian
‎2005 Nov 02 5:28 PM
Hi!
If you have only full key access, use hashed table.
If you also have partial key access (e.g. loop where), use sorted table.
Mostly used? Standard table...
Hash and sort algorithm cost a little bit in creation - if you add line by line and just make one read (for every line) later, than you have a lot of overhead. Then standard table, one sort and read with binary search is faster.
When you make table fills (select into table) and have a lot of accesses (on a hugh table), then hashed should be in his best.
Regards,
Christian
‎2005 Nov 02 5:32 PM
Hi,
for tables with many records (> 100?), the hashed table access by key will be definitely faster.
But note:
A hashed table allows unique keys only while a sorted table may have non-unique keys.
As the keys are not sorted but hashed, a loop at the hashed table will not regard any order.
Because only few developers understand the hash concept and, maybe, because nobody knows the hash algorithm and internal hashvalue length used by ABAP, one mighr not fully trust hashing...
Regards,
C.
‎2005 Nov 02 5:34 PM
There is no SAP recommendation... it is dependent on your needs.
Sorted tables store records in a "sorted" fashion at all times. It is faster to search through a sorted table vs a standard table. But performance is dictated by the amount of records in the internal table.
A hashed table's performance in reads is NOT dependent on the number of records. However, it is intended for reads that will return only and only one record. It uses a "side-table" with a hash algorithm to store off the physical location of the record in the actual internal table. It is not NECESSARILY sorted/organized in an meaningful order (like a sorted table is). Please note that changes to a hashed tables records must be managed carefully. Review SAP's on-help in SE38/80 about managing hashed tables.
‎2005 Nov 02 9:01 PM
Do know already the tipps and tricks on performance? Start Transaction SE30 the initial screen contains an according button.
Best Regards
klaus