ABAP - The right Key

Table of contents

• Introduction
• Types
• Key
• TYPE TABLE
• Working with Tables
• Complete Example
• Conclusion

In this article, we'll take a look at tables, how to define proper keys for your table, and what you should consider regarding performance.

 

Introduction

We repeatedly encounter the same table definitions in code reviews or in the SAP standard. Usually, a table is defined "carelessly" with TYPE TABLE followed by some structure or table. In principle, a developer can work with this, and if we're in the context of a report, we can also define other types with it. However, if we switch to object-oriented programming and want to define methods with RETURNING parameters, we immediately get the first error message that the type is not fully defined. Many developers probably then ask themselves, did I do something wrong?

 

Types

Basically, there are currently three types of tables: Standard, Sorted, and Hashed. In most cases, the Standard table was used back then, and not much thought was given to performance. Sorted and Hashed tables always require a key, so they are initially a bit more difficult to define. You should also consider at the beginning of development whether you have a unique key in the table or whether duplicate keys could cause problems later. Here are some different table definitions:

DATA standard_table TYPE STANDARD TABLE OF example_structure.
DATA sorted_table   TYPE SORTED TABLE OF example_structure WITH NON-UNIQUE KEY key_field.
DATA hashed_table   TYPE HASHED TABLE OF example_structure WITH UNIQUE KEY key_field.

 

The standard table has no key, so duplicate and empty records can be inserted. However, the records in the table are not sorted and are inserted sequentially. The sorted table has a non-unique key, so the same key can be inserted multiple times; however, the records are inserted and sorted according to the key in the table. The hashed table always requires a unique key, and the same rules apply as for the sorted table.

 

Key

We already defined keys in the example above, as these are mandatory for sorted and hashed tables. So, what about standard tables? Currently, there are two types of keys, which are defined as follows:

DATA table_default TYPE STANDARD TABLE OF example_structure WITH DEFAULT KEY.
DATA table_empty   TYPE STANDARD TABLE OF example_structure WITH EMPTY KEY.

 

The EMPTY key is SAP's actual recommendation; in this case, the table has no key, and no key management takes place. In contrast, the DEFAULT key is the so-called step key. Here, all character-type fields are used to generate the key. Depending on the structure, the key can then contain a very large number of fields, which in turn impacts performance during management, even though you might not even use the key.

Further information about the standard or default key can be found in the documentation below. There, it is also described in detail how the key is composed.

 

TYPE TABLE

If you simply define a table as TYPE TABLE, then you should first ask whether the developer doesn't know better, is lazy, or has no interest in the content of the table or the amount of data. This is no longer best practice.

DATA table TYPE TABLE OF example_structure.

 

Basically, you have now defined the following:

• Standard Table
• Default Key

 

Therefore, it would be better to specify the actual type right away, especially for new developers. Therefore, we would define the type of table here and indicate that the key is irrelevant to us and we don't need one:

DATA table_correct TYPE STANDARD TABLE OF example_structure WITH EMPTY KEY.

 

Working with Tables

We've already done a short series on working with tables in the past. In this series, we'll focus primarily on the new method using []. Additionally, we'll look at the performance of different table types so you get an idea of which type is right for you.

• Read
• Performance
• Example

 

Do you still use APPEND or do you use INSERT for everything? In this article, we'll look at the differences and give a recommendation on what you should actually use. Basically, we recommend that you think carefully about the type of data before you run into problems later. The following questions can help:

• How many records do I expect to process in this table?
• Will I process the records in a loop, or will I have read access via READ or []?
• Is there a key in the data? Is this unique?
• Do I often have to write the data or insert new data records?

 

Complete Example

To help you understand the example, here is the complete source code of the executable class. You can use this to load the class into the system and reproduce the behavior yourself.

CLASS zcl_bs_demo_table_keys DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PRIVATE SECTION.
    TYPES:
      BEGIN OF example_structure,
        key_field   TYPE c LENGTH 20,
        description TYPE string,
        number      TYPE i,
        date        TYPE d,
        time        TYPE t,
      END OF example_structure.

    METHODS types_of_tables
      IMPORTING !out TYPE REF TO if_oo_adt_classrun_out.

    METHODS type_table
      IMPORTING !out TYPE REF TO if_oo_adt_classrun_out.

    METHODS keys
      IMPORTING !out TYPE REF TO if_oo_adt_classrun_out.
ENDCLASS.


CLASS zcl_bs_demo_table_keys IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    types_of_tables( out ).
    keys( out ).
    type_table( out ).
  ENDMETHOD.


  METHOD types_of_tables.
    DATA standard_table TYPE STANDARD TABLE OF example_structure.
    DATA sorted_table   TYPE SORTED TABLE OF example_structure WITH NON-UNIQUE KEY key_field.
    DATA hashed_table   TYPE HASHED TABLE OF example_structure WITH UNIQUE KEY key_field.

    out->write( standard_table ).
    out->write( sorted_table ).
    out->write( hashed_table ).
  ENDMETHOD.


  METHOD keys.
    DATA table_default TYPE STANDARD TABLE OF example_structure WITH DEFAULT KEY.
    DATA table_empty   TYPE STANDARD TABLE OF example_structure WITH EMPTY KEY.

    out->write( table_default ).
    out->write( table_empty ).
  ENDMETHOD.


  METHOD type_table.
    DATA table         TYPE TABLE OF example_structure.
    DATA table_correct TYPE STANDARD TABLE OF example_structure WITH EMPTY KEY.

    out->write( table ).
    out->write( table_correct ).
  ENDMETHOD.
ENDCLASS.

 

Conclusion

In this article, we looked at the different types and basics of internal tables. Basically, the right type of table is crucial for your development, and you should give extra thought to how you want to create the table at the beginning. But please, no more using TYPE TABLE.

 

Further information:
SAP Help - Standard Key