Recommended max number of measures and dimensions and widgets

[erahal]

Hello,

We have an application developed that contain a big data model with around 5 millions records in the different tables combined.

The application contains some complex measure and aggregations requested by requirements design.

The sheets load fine when we have two widgets containing like a dozen of dimensions and a dozen of measures.

However some end users insists on displaying all KPIs/Measures and all data in one single sheet. For example in one sheets we have:

• 9 widgets:
  • 4 KPIs
  • 5 tables 
• 21 dimensions
• 51 measures, many contains complex aggregations

The sheets becomes barely usable especially when no filter applied

What is the standard recommendation for qliksense for a single sheet? how many widgets/dimensions/measure should we have a single sheet to not abuse the flexibility of self service?

Thanks

Elie

[rubenmarin]

Hi, I don't think there are specific number, it depends on complexity, number of users (and the number of interactions) and server resources.

You can add a calculation condition to the tables, so in example they are only calculated for a maxium of 10 dimensions, or when multiplying the number of dimensions and measures returns a number below 50, so less than 10 dimensions and 5 measures, or 5 dimensions with 10 measures.

You can also add a complexity value to the measures to make come count as 2 or 5 normal measures.

Another or additional option is to add a 'calculate' button, this button only switches a variable value between 1 or 0, and the tables only calulates when the variable=1, this way ayou avoid objects recalculatiing while the user selects its dimensions/measures

[marcus_sommer]

5 millions of records are form a Qlik point of view a rather small data-set. With a well designed data-model are usually no very complex aggregations needed and even by a rather overloaded dashboard it should not cause special performance issues.

Therefore I suggest to check at first the data-model and to consider changes in the direction of a star-scheme data-model. Ideally it ends with rather simple expressions in the UI like:

sum({< ... >} Value)

without the need of (nested) if-loops, aggr-constructs or interrecord-functions. 

- Marcus