Clear all

Dealing with null values in Multi-active satellite's identifier fields

Posts: 1
Topic starter
New Member
Joined: 8 months ago


we ran into an issue of having to deal with null values in multi-active satellites identifier fields due poor data.

We receive XML data with multiple generic child elements with unique code in them to tell which type of element it is.

F.ex we have a account which receives multiple balance types with unique type identifier which tells what kind of balance it is. Now due poor XSD this identifier is not required and we received records where this data was missing, resulting in an error in our loads, since the identifier was part of primary key and was not allowed to be null in the table.

Because of this we started thinking, how to make the load more resilient in cases like this.

Easiest option would of course be removing the field from the primary key in technical implementation and allowing it to contain null values but this solution seems bit ugly.

Second option would be to transform the load to a hub-link structure with balance type as new hub. This would follow the DV 2.0 structure but seems bit excessive just because of chance of receiving broken data.

Third option was to calculate separate hash for these identifiers with similar rules to business key hash calculation and include this hash in the primary key of the satellite.

This was something we didn't find any mention of so what are your thoughts on this type of implementation?

2 Replies