is it possible to have too many tables in a qlik model?

[mariorubbo]

I have an app modeled as a straight-star schema. There is 1 fact table and about 30 dimension tables. My initial dashboard has 2 widgets which only use 1 pairing of dimension and fact at a time ( dim1 + fact, dim2 + fact, etc.). Most of the dimensions are role-playing dimensions. After aliasing my dimension table 27 times, the speed of dashboard has gone down dramatically.

My question:

Does any query against a subset of tables cause Qlik to evaluate all the associated tables? I.e. even though I only care about the association of dim1 + fact, is it also somehow calling the other 26 dimensions?

I know that Tableau works that way when using the direct db method. Namely, any query against any individual table in the model causes a SQL statement with all the tables in the model joined. Does Qlik behave similarly to this?

[Gysbert_Wassenaar]

The number of tables isn't a problem. I've seen models with hundreds of tables. Without looking at your data model and chart expressions it's hard to say what's causing the performance problems you're talking about.

[Anonymous]

YES

CB.

[sudeepkm]

When you said speed are you referring to the Data Load time or the UI?

Please check the Memory and CPU consumed while loading of objects.

You can check the Information density and subset ratio of your data model and can find whether the association is robust or not.

[mariorubbo]

UI time.

[Anonymous]

Hi Mario,

I guess this is your question "Does any query against a subset of tables cause Qlik to evaluate all the associated tables?"

The answer is no, at least not according to QV claims. Especially because you have a star schema with one fact table - this is a design recommended by QV.

You can try just for the fun of it and combine all data in one wide table - if you do not use set expressions a lot, that should actually work faster. I cannot find the post but someone did an analysis on star schema vs. single wide table vs. snowflakes and singe wide table was the fastest with straight expressions. I am personally a big fan of star schemas and would not go one big fat table route for many other reasons.

[mariorubbo]

My challenge is I need the outer join behavior between the dimension table and the fact.  i.e. for my report, I need to show each row of one dimension table and then count the rows of the fact table per dim.  If a particular dimension row has no facts then I want to show "0".  If I combine all tables together then I lose any dimension rows that have no facts.

[rwunderlich]

When you said "After aliasing my dimension table 27 times" did that result in a large synthetic key table?

Can you post a screenshot of your data model from the table viewer?

-Rob

[Anonymous]

good point and in that case do not combine them. you just need to figure out why you are getting that warning message and address it. I would not ignore it.

[mariorubbo]