Difference between Standard table vs hashed table vs sorted table

[former_member671693]

Hi,

I have gone through so many thread to find the exact difference between Standard table vs Hashed table vs Sorted table. But Still I am not clear with exact difference.

1. when to use Standard table vs Hashed table vs Sorted table ?

[Sandra_Rossi]

I guess you know the technical differences between them (what is standard, what is sorted, what is hashed), by reading the official ABAP documentation.

The rest is just a matter of cost.

1. It costs performance to update a table if it has indexes.
2. It costs performance to read a table by key without an adequate index.
3. It costs memory to have indexes.

Usually, give more consideration to optimize performance costs rather than memory costs.

Based on that, use the solution with the lowest cost:

• If you need to write to an internal table and not read it (or not read it by key), use a standard table.
• Etc.

[michael_piesche]

Some pratical guidelines:

Standard Table:

• when you have less than 100 rows of data, just use standard table, anything else is overhead, UNLESS you need to read from these rows thousands of times by specific keys during execution of the program
• when you have thousands/millions rows of data, BUT you never read from them (e.g. you dump it to a CSV or XLS), just use a standard table
• worst case performance for search and delete O(n): it takes all n rows ('key' in row) to look at, to find the searched key in the worst case (sequential search)
• performance for insert O(1): A new row is inserted/appended without having to deal with key constraints

Sorted Table:

• when you need your table (always) sorted, obviously (you could use standard table and sort manually as well, but that is 'more' coding and is less efficient if you have to redo it during execution of the program)
• when you have a) lots of data and b) need to read from those often by a non-unique key (can be unique too of course) or c) need to access them by index
• worst case performance for search/insert/delete O(log n): it takes log n keys to look at, to find the searched key in the worst case (logarithmic search)

Hashed Table:

• when you have a) lots of data and b) need to read from those often by a unique key (cannot be non-unique) and c) you dont need to access them by index
• average case performance for search/insert/delete O(1): it takes one lookup to find the searched key on average (hash algorithm to 'find' the bucket and ideally there is only one key in the bucket)
• worst case performance for search/insert/delete O(n): it takes all n keys to look at in a hash index, to find the searched key in the worst case (hash algorithm to 'find' the bucket, but mostly sequential search in bucket itself)

In general, when it comes to reading/inserting/deleting, Hashed Table should outperform Sorted Table (and Standard Table will be so much worse than both regarding reading/deleting), but there can be instances depending on the data, where sorted outperformes hashed. If the number of rows is less then 10'000 or maybe even 100'000 (and there is not a disproportionate number of read access), you might not even note a difference between them as a user waiting for the execution to end (compared to Standard Table you will notice it as a user).

So it all depends on your requirements and, if necessary, you need to carefully plan the implementation and probably make performance tests with large test data using different table types. But if your test data strongly differs from your productive data, your test might be 'useless'.

[gasparerdelyi]

Hashed tables can have better performance only as long as you have the full key for accessing it for all your frequent accesses (or there are secondary keys supporting the rest). Furthermore hashed tables come only with unique keys and do not allow index access (via the primary key). Most usually this is the factor that determines if they can be used or not.

There are also different costs in memory consumption.

Most importantly: standard tables should not be used for huge amount of data with frequent key look-ups. Even if you sort them, only READ TABLE BINARY SEARCH can make use of the order (and LOOP/MODIFY/DELETE cannot without manual coding tricks).
There are some special use cases for standard tables with huge amount of data (the most typical is when you just append the rows, and at the end you loop over the whole table once and that is all) -- the developer needs to know what she or he is doing in the special cases,

[Former Member]

There is a section in the ABAP Documentation discussing this very topic:
https://help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/abenselect_table_type_guidl.htm

[Sandra_Rossi]

gabmarian It's worth an answer!

[matt]

From a robust programming perspective (which should always be considered before performance), use HASHED tables for preference, next SORTED tables and STANDARD tables only when you really have to (e.g. CL_SALV_TABLE).

I have never encountered, in 20 years, a performance or memory issue from following this guideline.

[former_member671693]

@gabmarian Thanks, I have gone through above link, and understood the difference clearly.

[former_member671693]

@gabmarian Thanks for providing this link. Perfect Answer. I am closing this thread.