We are about to receive a data feed where the source data is being pushed to us once per day, and each day represents deltas.
| SourceFileName |
| FILE_NAME_20250425210549.csv |
| FILE_NAME_20250426210417.csv |
| FILE_NAME_20250427210418.csv |
| FILE_NAME_20250428210412.csv |
| FILE_NAME_20250429210418.csv |
Given that we are about to receive a data feed with the historical changes/deltas already in them, is it simpler (and easier) to just load each record as a non-historized link/sat, since each record we receive is effectively a delta, and will not change in itself?
Good call, why check if the records are new if by default is that it is always new.
No hashdiff needed, just an unnecessary cost you can avoid
No need to check if it is a delta, another unnecessary cost you can avoid
1 Like
The definition of a Non-Historized-Link in DV2 is about relationships, which attributes never change. That saying: It‘s about the content of your files.
@patrickcuba is right in saying that you don‘t need the delta check on the way in. But that‘s a completely independent issue.
Another definition of an NHL: If you‘re modeling in Link and Sat and the relationship would be 1:1, then you can bring it into an NHL.
But please, don‘t make a ldts or a transaction/extract/update date the dependent child/transaction no (XCTN in the bootcamp). That‘s a misuse that breaks the standards.
Why would you need a dep-key in a NH-link/sat?