Creating Fields vs Dimensions

[lost_rabbit]

When do we decide to create something as a Field (adding it in the Script ) vs creating it as a Dimension on the front end ?
What are the nuances? For eg, say I need a YTD flag, should I add it as a field to the Data Model or just create a Dimension YTD flag inside the App ? 

Couldn't find answer to this question anywhere. So please share your knowledge and help me out 🙂 

[Nicole-Smith · Accepted solution]

How I think about it:

• Any calculations to fields that can be done in the script, I do in the script
  • This will make everything on the front-end work faster (since it's not calculating anything), so I follow this rule whenever I can
• After all of my fields are loaded in, I add as dimensions:
  • Any field I want to show in filter selections tool without checking the "all fields" box
  • Any field I want to use as a dimension on a chart
  • Any field I want business users to have the ability to use on a chart (because they will have access to Master Dimensions and Measures)

[marcus_sommer · Accepted solution]

Like usually the answer is: it depends. But as a more general recommendation if you could define information within a field in the script you should prefer it against building the logic within the UI. Reasons are:

• the UI performance is better with native fields
• you could use them within aggr() or total statements
• it's often much easier respectively the only sensible way to create them in the script
• reducing the complexity from UI expressions
• keeping UI expressions more readable
• probably some more

In your case with the YTD flag I suggest to create it within a master-calendar.

- Marcus

[lost_rabbit]

Thank you so much @marcus_sommer and @Nicole-Smith . If there's any article/blog that explains this in detail, please share

[marcus_sommer]

Your mentioned YTD example is usually a rather simple case because it could be mostly defined with a classical set analysis condition within an expression. For many other scenarios it wouldn't sufficient because the calculations would need any aggregation. In such cases you would need to wrap this aggregation with an aggr() and this only to emulate the field-generation within the UI. On top of it you may need easily further calculations which means to wrap an aggr() with another aggr() - means to create heavily nested calculations which requires beside a proper syntax a clear understanding on which inner- and outer part must which set analysis and other conditions be placed.

Of course this could be handled with some knowledge and experience but it will be always much more expensive as doing it in a more simple way and defining (nearly) everything possible within the script. Not fully fitting to your question but providing some insights to the challenges with aggr() showed this posting:

AGGR... - Qlik Community - 1475149

- Marcus

[Dalton_Ruer]

All of the above were spot on. A couple of additional things to consider:

Master Dimensions don't have to be different than fields. I frequently use simple fields as Master Dimensions so that I can add a Description, and so that I can assign colors to each value. That gives me the luxury of ensuring the same dimension values will have the same colors in multiple charts without me having to write a bunch of color expressions. It also let's me provide a level of TRUST to my end users. 

When I say TRUST I mean that often times in business there are multiple ways things CAN be done. Different regions look at things differently, or different departments look at things differently.  Imagine being an end user and seeing a KPI that says the "Days Sales Outstanding (DSO) is 20.25, but also seeing the chart that uses the dimension above and seeing that about 40% of the values are above 30 days, many that are 180 days or more." 

If the Master Items have descriptions the end user can easily hover over "Show Details" if we let them and see the descriptions. "Oh this is a weighted DSO value. That's not what my manager likes to see so I better not go screaming to him about this number." The goal for Analytics is ACTION. Somebody fixing/doing something as a result of insights. If they can't trust the numbers/answers/insights they see they are far less likely to act upon them. 

I recently wrote a post about yet another very dynamic way to accomplish the same thing and not even require end users to know they can ask for details. This solution is great for end users that will NOT have to modify charts or create their own. That's where the Master Dimensions and Master Measures are really handy. 

https://dataonthe.rocks/an-alternative-to-alternatives/