I think the best would be to avoid such a key-field. For joining your target-table you didn't need these key only date is enough. Are there joins to other tables? Then it could be a solution to create a bigger fact-table per joining and/or mapping and afterwards delete this key-field and use instead two fields "date" and "time" in your data-model.
I assume that it has been a requirement that we break down our target_value by minute so that we have all the possibilities - though we probably won't be able to calculate and display this every minute - so, yes, I do need that keyfield.
(those are the target_data which I then have to link to the current_data to show "where we are" production-wise)
Splitting such a thing in two saves a lot, I know, but I cannot use two separate fields as key without combining them, can I?
well, this is the critical question - it's probably me who is unclear about this.
AfaIk I cannot use two fields as key as long as they are separate, can I? This assumption is why I concatenate the date and the time (which looks like this)
num(Date_PK) & '_' & Interval_Min as Keyfield,
Of course, if I could leave those two fields separate and still use their combination(s) as key, that would save me a few million records. Would that work?
Afaik, you can use two separate fields.
from tableA.qvd (qvd);
load date_column as date_pk,
minute_column as minute_pk,
from TableB.qvd (qvd);
[date_column, minute_column, target_value
Output would still be