
The internal tables we have used so far had a scalar data type as their row type. In the example shown in the figures here, the row type of internal table numbers is the ABAP built-in type I.
We refer to these kinds of internal tables as simple internal tables.

We speak of a complex internal table if the row type is a structured data type.
While a simple internal table has only one nameless column, a complex internal table consists of several columns, each of them with the name and type of the corresponding component of the structured row type. In the example, the row type of internal table connection is a structured type with five components: carrier_id, connection_id, airport_from_id, airport_to_id, and carrier_name. Consequently, internal table connections has five columns with those names.

Up to now, we have addressed the rows of an internal table by their position. This is called an index access.
With the named columns of a complex internal table, key access becomes more important. Key access means addressing a row of the internal table by looking for particular values in particular columns. The columns in which you search can be any columns of the internal table.
Index access to an internal table is always very fast, even if the internal table contains many rows. Key access, however, can become very slow if the table contains a lot of rows. Choosing the right access type for the internal table can improve the performance of a key access.
Every internal table has one of three access types. The access type determines how data is stored in the table and, based on that, how the system reads the table to retrieve the data.
The different types of tables are as follows:
In this lesson, we will concentrate on standard tables. More information on sorted and hashed tables can be found in the ABAP documentation.

Every internal table has a key. In standard tables, the key does not play a particularly significant role. For sorted and hashed tables, the key is very important as it determines the way in which the data will be managed in the table. Crucially, sorted and hashed tables are only faster for key access that addresses all or at least a subset of the key fields.
A further attribute of the table key is its uniqueness. You will sometimes want to allow duplicate entries in an internal table, and sometimes you will want to ensure that the key is unique. Here, the following rules apply:
- Duplicates are always allowed in standard tables
- Duplicates are never allowed in hashed tables
- For a sorted table, you choose in the definition whether the key is to be unique or non-unique.