Second option, becasue that way qlik engine wouldn't have to evaluate another field possible values; also you could get rid of island table in data model whcih helps in performance. However, there is a catch, if you are going to use variable with expression definition, you also have to consider it's complexity.
Second option, becasue that way qlik engine wouldn't have to evaluate another field possible values; also you could get rid of island table in data model whcih helps in performance. However, there is a catch, if you are going to use variable with expression definition, you also have to consider it's complexity.
How "could getting rid of island table in data model will help in performance"?? I mean what impact they could have on performance as soon as we are not using them on frontend calculations.
If you don't use them in UI, then there is no significant performance issue. However, if you happen to use them, specially in a structure like - Sum(If... you would notice performance drop; worse it becomes with more data in table. This is because, in such scenarios qlik engine produces cross-join before it start evaluating the expression. Hence it's better to avoid island tables when feasible.
