Difference between cluster tables and pool tables

[Former Member]

What is the difference between cluster tables and pool tables..??

[Former Member]

Hi

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 cominied 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 strore control data. They can also be used to store temporary data or texts, such as documentation.

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.

[p190355]

Hi,

Table pools (Pools) and Table clusters (Clusters) are special Table types in the ABAP Dictionary.

The data from several (Small) different tables can be stored together in a Table pool or Table cluster.

(Large) tables assigned to a Table pool or Table cluster are referred to as Pooled tables or Cluster tables.

Table Pools

A Table pool or Table cluster should be used exclusively for storing internal control information

(screen sequences, program parameters, temporary data, continuous texts such as documentation).

Data of commercial relevance is usually stored in transparent tables.

A table in the database in which all records from the pooled tables assigned to the table pool are stored corresponds to a Table pool.

The Table pool's primary key consists of two fields:

1) TABNAME for the name of a pool table

2) VARKEY for the interdependent contents of the key fields in the corresponding pool table.

Table Clusters

Several logical data records from different cluster tables can be stored together in one physical record in a Table cluster.

A Cluster key consists of a series of freely definable key fields and a field (Pageno) for distinguishing continuation records.

A Cluster also contains a long field (Vardata) that contains the contents of the data fields of the cluster tables for this key.

If the data does not fit into the long field, continuation records are created. Control information on the structure of the data string is still written at the beginning of the Vardata field.

The intersection of the key fields of the cluster tables forms the Primary key of the Table cluster.

The Table type can be changed from Extras -> Change table type Category,

Cheers,

Remi

[former_member188685]

Cluster table can hold lot of information in cluster but here one table can hold many tables in cluster. Pool tables mean it is a pool of tables(there can be many tables).

[Former Member]

Hiii

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 cominied 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 strore control data. They can also be used to store temporary data or texts, such as documentation.

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.

Donot forgot to reward points

[babuabrahamgidla63]

Thanks for clear info. Thanks.

[former_member188685]

Check the SAP help

http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm

[Former Member]

Pooled tables

A pooled table in R/3 has a many-to-one relationship with a table in the database (see Figures 3.1 and 3.2). For one table in the database, there are many tables in the R/3 Data Dictionary. The table in the database has a different name than the tables in the DDIC, it has a different number of fields, and the fields have different names as well. Pooled tables are an SAP proprietary construct.

When you look at a pooled table in R/3, you see a description of a table. However, in the database, it is stored along with other pooled tables in a single table called a table pool. A table pool is a database table with a special structure that enables the data of many R/3 tables to be stored within it. It can only hold pooled tables.

R/3 uses table pools to hold a large number (tens to thousands) of very small tables (about 10 to 100 rows each). Table pools reduce the amount of database resources needed when many small tables have to be open at the same time. SAP uses them for system data. You might create a table pool if you need to create hundreds of small tables that each hold only a few rows of data. To implement these small tables as pooled tables, you first create the definition of a table pool in R/3 to hold them all. When activated, an associated single table (the table pool) will be created in the database.

Pooled tables are primarily used by SAP to hold customizing data. When a corporation installs any large system, the system is usually customized in some way to meet the unique needs of the corporation. In R/3, such customization is done via customizing tables. Customizing tables contain codes, field validations, number ranges, and parameters that change the way the R/3 applications behave.

Some examples of data contained in customizing tables are country codes, region (state or province) codes, reconciliation account numbers, exchange rates, depreciation methods, and pricing conditions. Even screen flows, field validations, and individual field attributes are sometimes table-driven via settings in customizing tables.

During the initial implementation of the system the data in the customizing tables is set up by a functional analyst. He or she will usually have experience relating to the business area being implemented and extensive training in the configuration of an R/3 system.

Cluster table

A cluster table is similar to a pooled table. It has a many-to-one relationship with a table in the database. Many cluster tables are stored in a single table in the database called a table cluster.

A table cluster is similar to a table pool. It holds many tables within it. The tables it holds are all cluster tables.

Like pooled tables, cluster tables are another proprietary SAP construct. They are used to hold data from a few (approximately 2 to 10) very large tables. They would be used when these tables have a part of their primary keys in common, and if the data in these tables are all accessed simultaneously. Table clusters contain fewer tables than table pools and, unlike table pools, the primary key of each table within the table cluster begins with the same field or fields. Rows from the cluster tables are combined into a single row in the table cluster. The rows are combined based on the part of the primary key they have in common. Thus, when a row is read from any one of the tables in the cluster, all related rows in all cluster tables are also retrieved, but only a single I/O is needed.

A cluster is advantageous in the case where data is accessed from multiple tables simultaneously and those tables have at least one of their primary key fields in common. Cluster tables reduce the number of database reads and thereby improve performance.

Restrictions on Pooled and Cluster Tables

Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. On a pooled or cluster table:

• Secondary indexes cannot be created.

• You cannot use the ABAP/4 constructs select distinct or group by.

• You cannot use native SQL.

• You cannot specify field names after the order by clause. order by primary key is the only permitted variation.

[Former Member]

Pooled Tables: Different tables which are not linked to each other with a common key can be combined into a Table Pool. The tables contained within this pool are called Pooled Tables. A table pool is stored in the database a simple table. The table's data sets contain, in separate fields, the actual key for the data set to be stored, the name of the pooled table and the contents of the data set to be stored.

Using this schema, several logical tables are combined into a single real database table. Although the data structure of each set is lost during the write to the table pool, it is restored during the read by the ABAP/4 Data Dictionary. The ABAP/4 Data Dictionary utilizes its meta-data to accomplish this.

Since information must be prepared (defined) within the ABAP/4 Data Dictionary when it is read or written to (or accessed), this process itself defines these as not transparent tables

Cluster Tables: Occasionally, several tables may be linked by a common key. The ABAP/4 Data Dictionary can also combine these tables into a single table. Each data set of the real table within the database contains a key and in a single data field, several data sets of the subsequent table for this key.

As mentioned above, these table types require special data handling, therefore they are not transparent tables.

[Former Member]

Hi

Table pools (pools) and table clusters (clusters) are

special table types in the ABAP Dictionary. The data from

several different tables can be stored together in a table

pool or table cluster. Tables assigned to a table pool or

table cluster are referred to as pooled tables or cluster

tables.

Table Pools

===========

A table pool or table cluster should be used exclusively for

storing internal control information (screen sequences,

program parameters, temporary data, continuous texts such as

documentation). Data of commercial relevance is usually

stored in transparent tables.

A table in the database in which all records from the pooled

tables assigned to the table pool are stored corresponds to

a table pool.

Table Clusters

==============

Several logical data records from different cluster tables

can be stored together in one physical record in a table

cluster.

A cluster key consists of a series of freely definable key

fields and a field (Pageno) for distinguishing continuation

records. A cluster also contains a long field (Vardata) that

contains the contents of the data fields of the cluster

tables for this key. If the data does not fit into the long

field, continuation records are created

Pooled table

Pooled tables can be used to store control data (e.g. screen sequences,

program parameters or temporary data). Several pooled tables can be

combined to form a table pool. The table pool corresponds to a physical

table on the database in which all the records of the allocated pooled

tables are stored.

Cluster table

Cluster tables contain continuous text, for example documentation.

Several cluster tables can be combined to form a table cluster. Several

logical lines of different tables are combined to form a physical record

in this table category. This permits object-by-object storage or

object-by-object access. In order to combine tables in clusters, at

least part of the keys must agree. Several cluster tables are stored in

one corresponding table on the database.

Pooled table

Pooled tables can be used to store control data (e.g. screen sequences,

program parameters or temporary data). Several pooled tables can be

combined to form a table pool. The table pool corresponds to a physical

table on the database in which all the records of the allocated pooled

tables are stored.

Cluster table

Cluster tables contain continuous text, for example documentation.

Several cluster tables can be combined to form a table cluster. Several

logical lines of different tables are combined to form a physical record

in this table category. This permits object-by-object storage or

object-by-object access. In order to combine tables in clusters, at

least part of the keys must agree. Several cluster tables are stored in

one corresponding table on the database.

award if useful

Regards Sravani

[Former Member]

Pool Tables (match codes, look up tables)

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

Cluster Tables (BSEG,BSEC)

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

IV. Buffered Tables (includes both Transparent & Pool Tables)

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.

pooled - many to one

cluster table - many to one

poolled and cluster table both are logical tables

Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.

A001,A004,A005,A006,A007,A009,A010,A012,A015,A016,A017,A018,A019,A021,A022,

Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.

AUAA,AUAB,AUAO,AUAS,AUAT,AUAV,AUAW,AUAY,BSEC,BSED,BSEG,BSES,BSET,CDPOS

Refer link: http://help.sap

[Former Member]

Thanks.

[Former Member]

Table pools (pools) and table clusters (clusters) are special table types in
the ABAP Dictionary. The data from several different tables can be stored
together in a table pool or table cluster. Tables assigned to a table pool or
table cluster are referred to as pooled tables or cluster tables.

A table pool or table cluster should be used exclusively for storing internal
control information (screen sequences, program parameters, temporary data,
continuous texts such as documentation). Data of commercial relevance is usually
stored in transparent tables.