Sorted, Hashed Or Standard – What Is Your Type?

When we declare a table in ABAP, we usually don’t think about what kind of table we want. We simply declare the table as a standard table.

DATA standard_flights TYPE STANDARD TABLE OF sflight.

This is very simple and easy to write but not best for the program performance. We should always consider the type of data and amount of data that is going to be put in that table.

I think there are two reasons for not using the table types correctly.

1. We don’t really understand when to use which type
2. We are not used to the syntax or don’t know the syntax at all so if we type in sorted/hashed table our code is not activated, we are unsure of the keys to use and we switch back to standard table. Happens with me all the times.

Let us look at solving these problems.

Typically, a standard table should only be used for small tables, when order of the records is not important or the records will be processed in a different order than the order in which they were appended or different accesses to the table are needed, say sorting and reading multiple times on different keys etc.

For larger tables, we should consider using a sorted table or a hashed table.

If the table needs to be sorted all the times on a specific key which are filled one by one (like appending one record at a time) and read large number of times – go for a sorted table.

And, if the table is read a whole lot of times but is filled at once, like through a select query and are not never modified – use hashed table.

With that in mind, let us look at the syntax.

"Standard
DATA standard_flights TYPE STANDARD TABLE OF sflight.

"Sorted
DATA sorted_flights TYPE SORTED TABLE OF sflight 
     WITH UNIQUE KEY carrid connid fldate.

"Hashed
DATA hashed_flights TYPE HASHED TABLE OF sflight 
     WITH UNIQUE KEY carrid connid fldate.

Few things to remember are as follows

1. Even though using default keys is simple to write – do not take short-cuts. We are learning this to avoid taking short cuts – so do not use default keys.

"Do not use this
DATA standard_flights TYPE STANDARD TABLE OF sflight 
     WITH DEFAULT KEY.

"Instead use non unique keys or empty keys
DATA standard_flights TYPE STANDARD TABLE OF sflight 
     WITH NON-UNIQUE KEY carrid connid.

DATA standard_flights TYPE STANDARD TABLE OF sflight 
     WITH EMPTY KEY.

2. Use INSERT INTO TABLE instead of APPEND TO which makes it possible to change the table type later.

INSERT VALUE #( ... ) INTO TABLE standard_flights.

This works as APPEND for standard table. For sorted and hashed table it adds the entry as per the keys specified.

3. Reading with index will not work in case of hashed table, we always have to use keys to read data from hashed table.

DATA(first_flight) = standard_flights[ 1 ].
DATA(first_flight) = sorted_flights[ 1 ].
DATA(some_flight) = hashed_flights[ KEY primary_key 
                                        carrid = 'AA' 
                                        connid ='0200' 
                                        fldate = '20210118].

4. When the tables needs to be read with different field combinations, create multiple keys.

DATA hashed_flights TYPE HASHED TABLE OF sflight 
     WITH UNIQUE KEY carrid connid fldate
     WITH NON-UNIQUE SORTED KEY sec_key COMPONENTS carrid connid.

"Read with primary key
DATA(some_flight) = hashed_flights[ KEY primary_key 
                                        carrid = 'AA' 
                                        connid ='0200' 
                                        fldate = '20210118].

"Read with secondary key
DATA(some_flight) = hashed_flights[ KEY sec_key 
                                        carrid = 'AA' 
                                        connid ='0200' ].

Note that primary_key is the name assigned implicitly to the primary key, but the name can be changed using key word ALIAS.

---

If you like the content, please subscribe…