Introduction to Tables & Indexces

The following three types of tables are available in SAP R/3:
¨ Transparent tables
¨ Pool tables
¨ Cluster tables





Transparent tables do exist with the same structure both in the dictionary as well as in the underlying database system, exactly with the same records and field descriptions.
The other two types cannot be directly queried in the underlying database, since those structures are only logically known at the SAP level. These structures can be found in the database but not in a directly readable form.






Pooled Tables, Table Pools, Cluster Tables, and Table Clusters


Pool and cluster tables are logical tables. Physically, these logical tables are arranged as records of transparent tables. The pool and cluster tables are grouped together in other tables, which are of the transparent type. The tables that group together pool tables are known as table pools, or just pools; similarly, table clusters, or just clusters, are the tables which group cluster tables.






* SAP recommends that tables of pool or cluster type be used exclusively for control information such as program parameters, documentation, and so on. Transaction and application data should be stored in transparent tables.






Generating the Table in the Database


Once a table is defined in the ABAP dictionary, it has to be created physically in the underlying database. The generation is performed automatically when activating the table using the ABAP dictionary functions.
There are, however, certain restrictions: only transparent tables are automatically generated. Pool− and cluster−type tables are not automatically generated since, from the database point of view, these type of SAP tables do not match database tables.
This implies that non-transparent tables cannot have secondary indexes, since secondary indexes, just as tables, must also be generated at the database level.






Indexes
The purpose of defining secondary indexes for tables (only for tables of type transparent) is to enhance the access time when performing select operations on the table. The secondary indexes allow access to the table information on which they are defined, using a different order than the one for the primary key. Physically, they behave like a record table subset, ordered by different criteria.
The secondary indexes do actually occupy physical space in the database; therefore, every table update implies a real updating of the secondary indexes. So, if defining secondary indexes helps the search performance, they, however, slow down the updating process.