Composite key performence issue

[sasikanth]

HI all,

I have 2 fact tables DAILY , SUMMARY (month wise)  andDimensions ,

now i need to create a link table by creating a composite key, i have 7 DIMs so 7 key fields are there,

now i have created a composite key with 7 keys fields ,

Now my question : is there any effect on performence if i create a composite key with 7 key fields?

if then please let me know what are they

Regards

Sasi

[sasikanth]

HI mohit,

is there any way to reduce number of keys in composite key,

in my scenario i have 7 common keys between Dim and both FACT tables,

and

if i use autonumberXXX() function At what extent it  reduce the effect on the performence ?

Please provide sample example if u  have.

Thanks

sasi

[#3]

LINK tables are known to have poor performance when there are many rows. If you have 7 dimensions, I will expect that you have many rows.

You may think another way to create your model: by concatenating your tables for example. If possible, of course.

See a post by HIC: http://community.qlik.com/blogs/qlikviewdesignblog/2012/10/26/mixed-granularity

Fabrice

[sasikanth]

HI ANUEZ,

Concatenating is not possible  in my scenario ,

Other than Link table and Concatenating ,is there any way to solve the problem ?

so that i can make my Data model perfect.

Thanks for the reply

Regards

Sasi

[#5]

I don't know.

Did you read the post by HIC about mixed granularity ? That is your scenario : some daily data, some monthly data. You have therefore a field named %Time to be generic that will contain months and days. Each %Time will point to day and month (3 fields in the link table) to perform the link and let the user do the choice. For the days that is evident, for the months the day part is null.

You concatenate the tables. You create some LINK dimension tables (one for each dimension where there is different granularity). HIC's solution works perfectly.

If your current LINK table is small, you will get no problem. It it contains several millions lines, I am not so sure.

Fabrice