3 ms·
Still does not make sense to me: OrigTableA = {(ruby, 5), (rust,7), (php, 3)} OrigTableB = {(red, 5), (black, 7), (purple, 3)} OrigTableA \cap OrigTableB wou
by laszlokorte 5y ago
Still does not make sense to me:
OrigTableA = {(ruby, 5), (rust,7), (php, 3)}
OrigTableB = {(red, 5), (black, 7), (purple, 3)}
OrigTableA \cap OrigTableB would be empty, makes no sense
OrigTableA \cup OrigTableB would conain all 6 elements, would be a SQL UNION, makes no sense for join
OrigTableA \times OrigTableB would be the the cross product:
{
((ruby, 5), (red, 5)), ((ruby, 5), (black, 7)), ((ruby, 5), (purple, 3)),
((rust,7), (red, 5)), ((rust,7), (black, 7)), ((rust,7), (purple, 3)),
((php, 3), (red, 5)), ((php, 3), (black, 7)), ((php, 3), (purple, 3))
}
Yes the cross product is what happens on a cross join (with the nested tuples being flattened) but now you have a single large set of all combinations and the filtering of only matching tuples (eg where the second element each tuple-pair matches) is simply not a binary operation on two sets but a unary operation on the single cross product set. Or if you tink of it as a binary pairing operation on the two original sets it is neither a set-union nor a set-intersection.
- stonemetal12 5y agoWe start with the cross product set, and apply the join on criteria as a subset operation to create the "background" of the venn diagram. We can then define a set "Table A" as the subset of the cross product where (as you have written it) the first element is not null. Same for Table B and the second element. Then joins are set-union and set-intersection between these two sets. I would agree that most people just flip up the diagrams without explaining what they are actually working with.