3 Answers
-
Best Answer
Former MemberPosted on Nov 30, 2007 at 04:48 AMHi chandra,
<b>Transprant tables:</b>
A transparent table in the dictionary has a one-to-one relationship with a table in the database. The database table has the same name, the same number of fields, and the fields have the same names as the R/3 table definition.They are used to hold application data. Application data is the master data or transaction data used by an application.
<b>Pooled Tables:</b>
A pooled table in R/3 has a many-to-one relationship with a table in the database .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.
Pooled and cluster tables are not usually used to hold application data but instead hold system data, such as system configuration information, or historical and statistical data.
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).
<b>Cluster Tables:</b>
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.
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.
<b>Restrictions on Pooled and Cluster Tables :</b>
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.
Regards,
Vijay
Add a comment
-
Former MemberPosted on Nov 30, 2007 at 04:58 AM
Hi
The following are the table types used in SAP :
I. Transparent tables (BKPF, VBAK, VBAP, KNA1, COEP)
Allows secondary indexes (SE11->Display Table->Indexes)
Can be buffered (SE11->Display Table->technical settings) Heavily updated tables should not be buffered.
II. 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
III. 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.
Transparent table - many to many
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.com/saphelp_nw04/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm
Reward if usefull
Add a comment
-
Former MemberPosted on Nov 29, 2007 at 10:26 AM
Hi Chandra,
Check this link
http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm
Thanks,
Vinay
Add a comment
Add a comment