Types of tables:

1. Transparent table
2. Clustered table
3. Pooled table

What is transparent, cluster and pool table? Where and when we use these tables?

Transparent Table : Exists with the same structure both in dictionary as well as in
database exactly with the same data and fields.

Pooled Table : Pooled tables are logical tables that must be assigned to a table pool when
they are defined. Pooled tables are used to store control data. Several pooled tables can be
combined in a table pool. The data of these pooled tables are then sorted in a common table
in the database.

Cluster Table : Cluster tables are logical tables that must be assigned to a table cluster when
they are defined. Cluster tables can be used to store control data. They can also be used to
store temporary data or texts, such as documentation.

What is the major difference between Standard tables, Pooled tables and Clusterd Tables?

A transparent table is a table that stores data directly. You can read these tables directly on
the database from outside SAP with for instance an SQL statement.
Transparent table is a one to one relation table i.e. when you create one transparent table
then exactly same table will create in data base and if is basically used to store transaction
data.

A clustered and a pooled table cannot be read from outside SAP because certain data are
clustered and pooled in one field.
One of the possible reasons is for instance that their content can be variable in length and
build up. Database manipulations in ABAP are limited as well.
But pool and cluster table is a many to one relationship table. This means many pool table
store in a database table which is know as table pool.
All the pool table stored table in table pool does not need to have any foreign key
relationship but in the case of cluster table it is must. And pool and cluster table is basically
use to store application data.
Table pool can contain 10 to 1000 small pool table which has 10 to 100 records. But cluster
table can contain very big but few (1 to 10) cluster table.
For pool and cluster table you can create secondary index and you can use select distinct,
group for pool and cluster table. You can use native SQL statement for pool and cluster
table.

A structure is a table without data. It is only filled by program logic at the moment it is
needed starting from tables.
A view is a way of looking at the contents of tables. It only contains the combination of the
tables at the basis and the way the data needs to be represented. You actually call directly
upon the underlying tables.
Standard table:
The key access to a standard table uses a sequential search. The time required for an access
is linearly dependent on the number of entries in the internal table.

You should usually access a standard table with index operations.

Sorted table:
The table is always stored internally sorted by its key. Key access to a sorted table can
therefore use a binary search. If the key is not unique, the entry with the lowest index is
accessed. The time required for an access is logarithmically dependent on the number of
entries in the internal table.

Index accesses to sorted tables are also allowed. You should usually access a sorted table
using its key.

Hash table:
The table is internally managed with a hash procedure. All the entries must have a unique
key. The time required for a key access is constant, that is it does not depend on the number
of entries in the internal table.

You cannot access a hash table with an index. Accesses must use generic key operations
(SORT, LOOP, etc.).

The tables may be

<b>
I. Transparent tables (BKPF, VBAK, VBAP, KNA1, COEP)</b>

Allows secondary indexes (SE11->Display Table->Indexes)

Can be buffered (SE11->Display Table->technical settings) Heavily updated tables

should not be buffered.
<b>
II. Pool Tables (match codes, look up tables)</b>

Should be accessed via primary key or

Should be buffered (SE11->Display Table->technical settings)

No secondary indexes

Select * is Ok because all columns retrieved anyway

<b>
III. Cluster Tables (BSEG,BSEC)</b>
 Should be accessed via primary key - very fast retrieval otherwise very slow

No secondary indexes

Select * is Ok because all columns retrieved anyway. Performing an operation on

multiple rows is more efficient than single row operations. Therefore you still want to
select into an internal table. If many rows are being selected into the internal table,
you might still like to retrieve specific columns to cut down on the memory required.

Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported

Can not be buffered

<b>
IV. Buffered Tables (includes both Transparent & Pool Tables)</b>

While buffering database tables in program memory (SELECT into internal table) is generally
a good idea for performance, it is not always necessary. Some tables are already buffered in
memory. These are mostly configuration tables. If a table is already buffered, then a select
statement against it is very fast. To determine if a table is buffered, choose the 'technical
settings' soft button from the data dictionary display of a table (SE12). Pool tables should all
be buffered.

<a href="http://www.sap-img.com/abap/what-are-different-types-of-internal-tables-and-
their-usage.htm">Different Types Of Internal Tables</a>
<a href="http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm">Different
Types of SAP Tables</a>
Creating a secondary index

There are two types of indexes: Primary index and secondary index.
Primary index is automatically created using the primary keys defined.
Secondary index could be created as per the user requirement. This article discusses about
creating a secondary index.
Go to transaction SE11.

For our demo purpose, we have considered the table ZAUTHOR.

To know if there are any secondary indexes available, click on Goto Indexes

Following popup appears:

From the above screenshot, it is evident that there are no secondary indexes already created.

Click on Create Create Index

Enter the name of the index.

Fill in the details Short description and the fields in the index.
Save and activate.

Now you can observe the index created above in the list now:

Maximum number of secondary indexes we can have are 9.

How to make SELECT statement to make use of any particular secondary index?
What to keep in mind for secondary index?

https://help.sap.com/saphelp_nw70/helpdata/en/cf/21eb2d446011d189700000e8322d00/content.htm

Indexing in SAP tables

https://wiki.scn.sap.com/wiki/display/profile/2007/09/19/Indexing+in+SAP+Tables

Metadata:
https://en.wikipedia.org/wiki/Metadata
http://whatis.techtarget.com/definition/metadata