How to Start Loving the Qlik Synthetic Key

Have you learned to love the Qlik Synthetic key without worry?

Love Qlik synthetic key? What a thought?

Some called it Maverick. Others would agree. Most Qlik Partners would strictly have protocols to permanently repair or remove synthetic keys, explicitly disallowing their inclusion. Even the reference manual states,

“ QlikView may or may not handle them gracefully’ and “Unfortunately the actual limitations are virtually impossible to predict” [with synthetic keys in place].

There has been much debate regarding the Synthetic Keys and their impact on performance.

What is a Synthetic Key?

Well, quite simply, a synthetic key is created in Qlikview when 2 or more tables have 2 or more fields in common:

So how can we learn to love them?

The hypothesis raised the idea that Synthetic keys have a terrible reputation for causing memory and performance issues. It is potentially pointless to spend development time and effort on creating composite keys as a correction. This hypothesis is backed up with statistical analysis from test results that show memory and performance to be marginally different, sometimes even better results, as recorded in a model with Synthetic keys compared to its Composite Key counterpart. The hypothesis further said that synthetic keys merely highlighted “mistakes” in the model, and the automatically created key incorrectly received the blame.

So should we love the Synthetic Key? because Qlik automatically does what we need to correct manually? Or have made provisions for in the design?

Is the warning you receive just a warning? Would you simply close it and move on? Have you stopped worrying?

Has it become a case of “Synthetic Keys may not be a bad thing?”

Well, the hypothesis went on in controversy, and through trial and error, the impact on more complex and detailed models came into a review. Again the question stands: “Does it go back to a weak model design that causes the Memory and Performance issues. Because yes, as the data in the model grows, the likelihood of additional keys grows with it. Finding the model “design flaw” or synthetic key that, when removed, resolves the performance issue, may take significant time. Additionally, on these larger-scale models, it is recorded that models that include the creation of synthetic keys DO increase reload time rather significantly.

The hypothesis shows reload time in memory and performance tests.

So to question whether or not to use the Qlik Synthetic key goes down to best practice, size, and lifespan of the model or solution.

Suppose you’re happy with the knowledge that your application will never really advance or grow. In that case, additional load time is not a factor for the solution, and that the tested result with a synthetic key has minimal impact. Then you may be happy to keep it in place.

---

Up Next: Learn About the Qlik Peek Function.