In my opinion, using JOIN in the load is almost always a bad idea. Duplicate values are created where there is a one to many join and this runs the risk of giving incorrect values, it also hurts performance. Associations (i.e. multiple tables in the Qlik data model) are almost always better, but as you rightly say can slow things down in the front end. You may be pleasantly surprised at how efficient Qlik is at dealing with these. Bringing dimension tables into your fact tables is a different case altogether, using ApplyMap to bring in simple ID/Value type dimension values is always a good idea, and doesn’t carry the risk of a join. I’ve other posts on this kind of subject on this blog.

Hope that helps.

Thanks for your reply. (I saved $1,000,000 :D)

Actually, I think I used a wrong word, i think I should use “JOIN” rather than “CONCATANATE” because these tables could be joined with a key.
What I am thinking is, should we join these tables thru the scripts to form the data model, rather than to let Qlikview to join on the fly thru the app. Thinking if join on the fly with these huge tables, will have great impact on performance. Any thought?

That is the $1,000,000 question.

For pure performance concatenation would be best (create QVDs with identical columns so you can do an optimised load from all of them), but this can break important associations between data types. If that is the case, and performance is ‘okay’ then a link table may be better. I’ve had a case where we couldn’t get the performance from a link table, due to data volume, so had a single fact table and build associations manually using Set Analysis and the P() function.

If you can make sure it is purely facts in your concatenated fact table and you have all dimensions values off to the side then often then association issues can be avoided anyway.

If the fieldname is always [Actual 2013] then the Year is always 2013 – so you can just hard code this (2013 as Year,). I suspect that you have more than one column with years in though? If so, what you need to use is the CROSSTABLE function, so, if you have data like this:

Product,Region,Actual 2013,Actual 2014,Actual 2015 etc. etc.

You would need to do:

Temp_Table:
CROSSTABLE (ColumnHead,Value, 2)
LOAD
*
FROM DataSource.qvd (qvd);

Table:
LOAD
*,
right(ColumnHead, 4) as Year
RESIDENT Temp_Table;

Hopefully I’ve second guessed your data structure correctly and that gives a solution, or if not, it points in the right direction?

Guys please help me on the below query,

I have a field [Actual 2013] and i want to take Year from the field. Suggest me in this.

Waiting for your reply.

Thanks
Ali

Thanks Washington. It’s amazing how many people think you can just use a RDBMS style data model and still have it perform.