cluster table

[Former Member]

how can we use the cluster table in the select statement? i have written one select statement with join.. its giving error like cluster tabled can not be useed in joins..

can anybody tell me the clue what should i do in this case?

thanks,

pandu.

[Former Member]

Hi,

See following link:

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3c60358411d1829f0000e829fbfe/content.htm

Reward points if helpful.

Regards.

Srikanta Gope

[Former Member]

Hi

You can't use JOINS for joining the Cluster and POOL tables with the transparent tables

first write a select for the transparent table

and ofr all entries of this transparent tables entries fecth the cluster/pool table entries

exa: BKPF and BSEG

where BKPF is transparent and BSEG is cluster

Select bukrs belnr gjahr budat wrbtr

from bkpf into table ITAB

where bukrs = p_bukrs and gjahr = p_gjahr and budat in S_BUDAT.

if not itab[] is initial

select belnr gjahr bukrs and ebeln werks from bseg

into table iTAB1 for all entries in itab

where bukrs = itab-bukrs and

belnr = itab-belnr and

gjahr = itab-gjahr.

endif.

<b>Reward points</b>

Regards

[Former Member]

Hi,

You cannot write join for cluster tables like BSEG..Instead you can use FOR ALL ENTRIES options..

EX..

DATA: T_BKPF TYPE STANDARD TABLE OF BKPF,

T_BSEG TYPE STANDARD TABLE OF BSEG.

SELECT * FROM BKPF

INTO TABLE T_BKPF

WHERE....

IF NOT T_BKPF IS INITIAL.

SELECT * FROM BSEG

INTO TABLE T_BSEG

FOR ALL ENTRIES IN T_BKPF

WHERE BUKRS = T_BKPF-BUKRS

AND BELNR = T_BKPF-BELNR

AND GJAHR = T_BKPF-GJAHR..

ENDIF.

Reward all helpful answers,

Regards,

Omkar.

[Former Member]

i dint understand the query.. can u pls explain?

[Former Member]

Hi Pandurangarao,

In the first Query,

<u><b>Step1:</b></u>

we would like to select "<b>article_id</b>" from the table pub_articles.

<u><b>Step2:</b></u>

Here we would like to compare the primary keys of pub_articles table which are respectively

a) "<b>article_id</b>" and

b) "<b>publication_id</b>"

against the foreign key table article_edition_lookup.

<u><b>Step3:</b></u>

Providing the date for pub_articles through the functional field "<b>publication_date</b>" along with validation of "<b>publication_id</b>" from this table.

Please feel free to ask for any more queries...

Regards,

Dhayanandh.S

[Former Member]

Hi

Cluster Tables (BSEG,BSEC)

Should be accessed via primary key - very fast retrieval otherwise very slow

No secondary indexes

<b>Select *</b> 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

Reward all helpful answers

Regards

Pavan

[Former Member]

CLUSTER TABLE is a table which has one TABLE in the DATABASE mapped to several tables declared in the Data Dictionary.

That is Severl DDIC tables data will be stored in One database table.

That is the reason why you cannot JOIN a cluster table as the underlying databse table has data from othertables also.

Cluster table is to group some of the related tables and to store the data in archive format.

For a normal transperent table there is one Databse table. so you can JOIN with a normal transperent table.

SAP Table Types

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.

also refer the link for examples

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3c60358411d1829f0000e829fbfe/content.htm

regards,

srinivas

<b>*reward for useful answers*</b>

[Former Member]

Hi Pandurangarao,

<u><b>General Tips:</b></u>

1.Test using the NativeDB engine.

2.Testing against another engine is not adequate.

3.Avoid JOIN if you can, test often if you can’t

4.Avoid subqueries always

5.Select using primary keys when at all possible.

6.Always select using a key.

7.Be sure to include both your where and order by columns in your keys.

8.Try your join from several directions.

Sometimes, the way you join can affect the engine. This is more apparent with Native DB than MyISAM or InnoDB. Have a look at these two queries:

<u><b>QUERIES</b></u>

select pub_articles.article_id

from pub_articles

inner join article_edition_lookup on

pub_articles.article_id=article_edition_lookup.article_id and

pub_articles.publication_id=article_edition_lookup.publication_id and

publication_date=’2007-06-07&#8242;

where pub_articles.publication_id=2;

select article_id

from article_edition_lookup

inner join pub_articles using (article_id, publication_id)

where publication_id=2 and publication_date=’2007-06-07&#8242;;

<u><b>Conclusion of the Queries:</b></u>

They look similar.

Same tables.

Same basic criteria.

In fact the explain output looks nearly identical.

But, the first takes 20 seconds on cluster and the second takes .02 seconds. Now, some MySQL internals person may be able to look at this and know why, but to me, I just have to test them to see.

(If anyone cares, the primary key on pub_articles is publication_id, article_id and the PK on article_edition_lookup is publication_id, publication_date, article_id).

Regards,

Dhayanandh .S