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?

[mariorubbo]

posted below.  Thanks to everyone for helping me with this

[cjzimm76]

Reduce the number of tables by doing a Left Join or a Mapping Load.

[Anonymous]

sorry we cannot see column names and this is the important piece

[mariorubbo]

[Anonymous]

it looks good to me. I assume in your charts you use ".._band_name" columns not band one. Like you said if you do a join or a mapping load that would not behave like outer join in SQL so I am not sure what else you can do here but i will let others chime in.

Possibly you can make a small improvements like check if you do not have too many distinct values for every .._band column (the less are better). Also if you .._band key is a text value, you might try to convert it to a number using autonumber function - it helps somewhat on really large documents.

[mariorubbo]

ok.  Thanks.  So bottom line, there is nothing theoretically wrong with a model that has this many tables and you answered my original question about the query behavior against a subset of tables.  Thanks for the info

[Anonymous]

pretty much...another way of doing role playing dimensions is to build linked tables but it might actually work much worse for you because now the hops between your fact table and a final dimension will be done though another table.

I think you did a good job - I would just look if you can optimize you keys and minimize number of distinct values - the more distinct values you have as your keys, so slower it will get.

[#9]

YES. Just take care of the NULLS - otherwise transactional details will disappear with a weak dimensions design