Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

Cartesian product in workflow

Milan_Vucetic
Community Advisor
Community Advisor

Hi all,

 

we noticed a bigger number in output then in input for some SMS recurring deliveries.

milanv69354962_0-1580737286278.png

After checking, a cross join is performed for customers with more mobile phones and that is the reason for bigger number. (We have several records for the same recipient with different mobile phones which customer poses in recipient table.)

 

I am trying to find out why is used the cross join here as target mapping is done on mobile number level.

Any idea?

 

Regards,

Milan

1 Accepted Solution
wodnicki
Correct answer by
Community Advisor
Community Advisor

Hi,

 

Recipients exist as duplicates in recipient table for each of their phones?

NB not cross join- recipients exist on left side for the numbers.

 

Thanks,

-Jon

View solution in original post

5 Replies
wodnicki
Correct answer by
Community Advisor
Community Advisor

Hi,

 

Recipients exist as duplicates in recipient table for each of their phones?

NB not cross join- recipients exist on left side for the numbers.

 

Thanks,

-Jon

View solution in original post

Milan_Vucetic
Community Advisor
Community Advisor

Hi @wodnicki,

well primary key is unique but there are customers with the same name/last name with different mobile phones. Generally, these are not duplicates as phone number is different. In output transition cross join is performed: If we have customer with 4 different numbers , we got 16 records (first 4 records with one number, second 4 records with other number, etc).

 

Anyway, output count should not be greater than input.

 

Regards,

Milan

wodnicki
Community Advisor
Community Advisor

Oh it is a cross-join, numbers seemed too close for that. Wait how are the numbers stored? Mobile is a field in recipient not a relation?

Milan_Vucetic
Community Advisor
Community Advisor

Hi @wodnicki,

yes it is just a field without relation. I have thougth this is a reconciliation key according to target mapping below:

milanv69354962_0-1580760539949.png

But as we have more records (just for SMS deliveries) probably is something else reconciliation key.

Anyway, we are fine with number of real sent SMS but in workflow these numbers is ugly.

 

I am thinking if control group can be reason somehow.

 

Regards,

Milan

wodnicki
Community Advisor
Community Advisor
Could also be personalization in the delivery creating an unexpected join. Tracing the db queries is an easy way of just seeing what's happening, if you have the access.