SQL joins illustrated as Venn diagrams

[SlurrerOfSpeech]

In my opinion, using Venn diagrams, or set theory in general, to help aspiring SQL programmers (yes, SQL is a programming language) understand joins causes nothing but confusion for literal-, logical-thinking persons like myself. Allow me to explain my opinion.

Venn diagrams have always been used to show operations on sets of elements of the same type. SQL tables are not sets because they can contain repeated elements (identical rows). But let's pretend for a moment that they are sets. Still, an inner join, for example, doesn't necessarily make sense as an intersection because the two sets being intersected do not necessarily consist of the same types of elements. The following

A = { dog, cat, horse, lizard }
B = { cat, mule, hamster, dog }
A intersect B = { cat, dog }

simple example of an intersection makes sense because the sets have the same types of elements (animal names). A join is nothing like an intersection because A and B can be of different elements and the result can be an entirely new type of element.

By the way, you guys should add more prefixes so I don't have to arbitrarily tag this as C/#/++ in order to satisfy the prefix reguirment.

 

[Mark44]

In my opinion, using Venn diagrams, or set theory in general, to help aspiring SQL programmers (yes, SQL is a programming language) understand joins causes nothing but confusion for literal-, logical-thinking persons like myself. Allow me to explain my opinion.

Venn diagrams have always been used to show operations on sets of elements of the same type. SQL tables are not sets because they can contain repeated elements (identical rows). But let's pretend for a moment that they are sets. Still, an inner join, for example, doesn't necessarily make sense as an intersection because the two sets being intersected do not necessarily consist of the same types of elements.

There is nothing in the definition of a set that says the elements have to be of the same type. From wikipedia, a set is "a collection of distinct objects".

The following

A = { dog, cat, horse, lizard }
B = { cat, mule, hamster, dog }
A intersect B = { cat, dog }

You could just as well have this:
A = { dog, 7, granite, shovel }
B = { mule, dog, pinwheel, hammer }
$A \cap B$ = {dog}

simple example of an intersection makes sense because the sets have the same types of elements (animal names). A join is nothing like an intersection because A and B can be of different elements and the result can be an entirely new type of element.

By the way, you guys should add more prefixes so I don't have to arbitrarily tag this as C/#/++ in order to satisfy the prefix reguirment.

 

[Samy_A]

A join can be described as a set, more precisely as a subset of the product of the joined sets.

Whether it is helpful or not is a matter of taste.

Technically an SQL table can contain identical records, using a primary key takes care of that.

 

[Mark44]

By the way, you guys should add more prefixes so I don't have to arbitrarily tag this as C/#/++ in order to satisfy the prefix reguirment.

The tag is not required, but I agree that we should have more tags.

Since your post isn't about C, C++, or C#, I am removing that tag.