Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Dear all,
Please see attached table Viewer, Mainly I have three table with Branch & Date field common in those table.
How to get rid of this synthetic key? Do it need to merge this two fields?
Please give me some idea.
Regards
Vinay
Given the data model, you must have either the synthetic key, or a composite key that you create yourself (e.g. like Massimo suggests below). There should be no major performance difference between the two solutions. Then synthetic key will probably use slightly less memory.
My concern is that you think you need to remove the synthetic key because you've heard that they're bad. But I can assure you that in your data model the synthetic key is not bad. More likely, it is the optimal solution.
HIC
It really depends on how your data is set up, joining different tables could be an option
Here's a blog post that may help http://community.qlik.com/blogs/qlikviewdesignblog/2013/04/16/synthetic-keys
Hi
you can rename the field or create composite key to resolve this.
Below post might help you.
http://community.qlik.com/blogs/qlikviewdesignblog/2013/04/16/synthetic-keys
Regards
ASHFAQ
If you think that the data model is correct - that you need to have both Branch & Date as keys in the concerned three tables - then you do not need to get rid of the synthetic key.
HIC
you can read
http://community.qlik.com/blogs/qlikviewdesignblog/2013/04/16/synthetic-keys
Should We Stop Worrying and Love the Synthetic Key?
you can remove in different ways
FieldName1 &'|'& Fielname2 as new_key
autonumber(...) as new_key
autonumberhash... ( ...) as new_key
Hi Henric,
My data model is correct. let me explain those three tables:
1. Table(Targets) - have daily sales & margin target by date and branch.
2.Table(Branch_salesdata2014) - have daily transaction data by date and branch.
3.Table(CallDetails) - have daily phone calls details by date and branch.
Do I need to keep the synthetic key?
Thanks for reply.
Vinay
Given the data model, you must have either the synthetic key, or a composite key that you create yourself (e.g. like Massimo suggests below). There should be no major performance difference between the two solutions. Then synthetic key will probably use slightly less memory.
My concern is that you think you need to remove the synthetic key because you've heard that they're bad. But I can assure you that in your data model the synthetic key is not bad. More likely, it is the optimal solution.
HIC