My first question mark is why in SQL, if I make left join between Temp which has 753878 lines and Relations with 4120 lines, the result table has 753881 lines and not 753878 as first table? May be because in Relations can be duplicates?
Exactly. The LEFT JOIN means you won't get any records from Relations that don't join to a row in Temp. However, if two different rows from Relations join to the same row in Temp, that row will be duplicated - once for each of the two different Relations values.
Why are you trying to replicate this functionality in QV anyway? Unless you have a good reason to, let SQL do what it is good at, which is basic joins to present a limited subset of data. Otherwise, you will slow your load script down unnecessarily. Take the following situation:
Table TempIT in your SQL database has 50,000 rows.
Table Relations in your db has 100,000 rows.
Only 25,000 rows in Relations are linked to TempIT.
SQL SELECT * FROM TempIT LEFT JOIN Relations ON....;
This will take x seconds to run and will present 50,000 rows (plus any duplicate joins) to QlikView, which is all it needs. SQL deals with basic joins very efficiently and so db load shouldn't be a worrysome factor.
However, if you load the entire TempIT table into a QVD, then load the entire Relations table into a second QVD, then use QlikView to join them, it first has to load both tables then perform the joins. This will most likely take longer than letting SQL join the data and QV needs to deal with 150,000 rows of data whereas it only really needs to see 50,000. Plus you are asking SQL to return 150,000 rows of data instead of only 50,000.
So, unless you NEED all the Relations data inside a QVD file (maybe for other uses - even then I would question whether you should use it here) then let SQL do what it is good at (basic stuff) and do the clever bits in QV.
If you're dealing with non-DB files then a structure of QVD files may well make sense. Your example above speaks of 2 SQL tables with a known join however, so I was referring to that situation with my comment above.