Difference between Cluster table and INDX-type table

[MarcinPciak]

Dear Friends,

I've read a lot about table Clusters and INDX-type tables (databases), like table PCL1, PCL2 ....

Both are used to store data clusters , but I am trying to uderstand why first one is defined as cluster table type in Dictionary, whereas the second as transparent table .

I know that both differs in structure (which is predefined for them). But here is some confusion:

Why SAP distinguished b/w cluster tables and INDX-type tables if they are used to store similar data type (RAW or LRAW), i.e. why PCL2 table can't be of cluster table type?

Maybe cluster tables are solely used to group logically connected transparent tables? But what therefore we need the latter for?

Thanks for sharing your opinion

Marcin

[Former Member]

Hi Marcin,

As i thought, transparent table and cluster table are different in use.Transparent table is used to hold application data where application data is the Master data or Transaction data used by an application.

whereas a 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.

regards,

Archana

[MarcinPciak]

Thank you Archana for your answer.

I understand the general difference b/w transparent and cluster tables. I was rather curious about INDX-type transparent tables which has specific structure, but I don't exactly get the role they play in storing data. If there are cluster tables (which can store RAW data, so why do we need INDX tables for? ).

I think also confusing is naming used here. We distinguish

- cluster tables

- data clusters which are stored in INDX-type tables.

So both tell about clusters, apparently name cluster would denote bundled data which is compressed and stored as RAW data.

Does anyone know if this is correct understanding?

Thank you

Marcin

[Former Member]

hi,

after reading several things about indx and cluster tables i came to the conclusion that :

1. indx tables are basically being used for storing data clusters : like we can store elementary fields, structures and tables in indx table .

2. whereas cluster tables are used for storing table clusters ... so this means that they are specially being used to store only several different tables ....

there is also a method to store data clusters ... which the abap guys use it... like export statement .... so i think that to store many values keeping and in mind about the restriction of abap memory / shared mem they must have came with this indx table for storing the data clusters separately.

hope this will help you!!

thanks & regards,

Punit Raval.

[MarcinPciak]

Hi Punit,

1. indx tables are basically being used for storing data clusters : like we can store elementary fields, structures and tables in indx table .
2. whereas cluster tables are used for storing table clusters ... so this means that they are specially being used to store only several different tables ...

You brought me great thing to my mind, the purpose would be as you say that different object types can be stored in both.

there is also a method to store data clusters ... which the abap guys use it... like export statement .... so i think that to store many values keeping and in mind about the restriction of abap memory / shared mem they must have came with this indx table for storing the data clusters separately.

And this is what I wanted to hear. I just realized that using EXPORT ... TO MEMORY ID 'MY_ID' we in fact are addressing clusters directly in the memory. This is because the cluster is kind of area identified by some id (here MY_ID identifies this area where we can store different kind of objects). And as you say INDX-type tables just easies handling that objects.

Last thing which I came conclusion to, is that SAP designers may wanted to give a relief to Application Server (by storing cluster data in memory) and decided to move that to DB -> hence create INDX-type tables. The way we are addressing both has changed slighty, but technical solution behid this differs.

Many thanks for giving me this idea:)

Regards

Marcin