4 ms·

Honestly, if it were not for Venn diagrams, I may have never learned how SQL joins work. It might not be perfect, but if you'd tried to make 16-year-old me unde

Honestly, if it were not for Venn diagrams, I may have never learned how SQL joins work. It might not be perfect, but if you'd tried to make 16-year-old me understand relational algebra in order to grok how the joins in his Django site were working, he'd have given up before he began. That's not to say that other ways of illustrating things don't have merit, but broad statements like "say NO to Venn diagrams" just aren't helpful. If people find Venn diagrams a useful tool (and their proliferation indicates they do), I don't see the harm. They didn't stop me going deeper on stuff like relational algebra when I was ready to.

Boxxed 8y ago
Maybe you didn't read the article? He presents a pretty nice visual alternative to Venn diagrams.
- obeattie 8y ago
  I did read the article and I don't find what the author thinks is a "nice illustration of a cartesian product" easy to grok at all. Similarly, I think I would have found the the diagrams further down hard to understand versus a Venn diagram. But that wasn't my point; if other people find these illustrations helpful, that's awesome and I wouldn't want to stop someone inventing something new and useful. My point was that I violently disagree with one-size-fits-all proclamations like "Say NO to Venn Diagrams."
- zzbzq 8y ago
  The hardest part of joins is remembering which is which. Venn diagrams are used specifically because they solve that problem with the inner/outer/left/right terminology. His visualizations ultimately help nothing. You have to stare at them for a while to see what the pattern is, but there's absolutely no mnemonic hook to remember what's what, so in the end all you learn from his visualizations are that there exist different ways to slice and dice the products of sets, which is already a given if you're trying to figure out what the differences are.
  - 40four 8y ago
    The author's diagrams aren't perfect either, but I think they are much more clear to novice coders about the real workings of joins. Check this out, similar to the author's approach, but animated. This is the best visual of SQL joins I've ever found. https://news.ycombinator.com/item?id=16983007 https://news.ycombinator.com/item?id=16983007
  - lloyd-christmas 8y ago
    For me, I still have no idea what the visual of a venn diagram is trying to tell me within the context of SQL. Just having a visual that I can't even understand does nothing to benefit the situation either.
hinkley 8y ago
The thesis is Say no to Venn diagrams for Joins. The first section is about how Venn works fine for AND and OR because it’s set theory and Venn works just fine for examples (maybe not every problem though). Joins are not sets. They are Cartesian products.
- y4mi 8y ago
  I'll be honest: if I didn't know SQL already, I would have no idea what his diagrams are trying to convey... I do know at this point that he is technically right... But being 100% correct doesn't really matter at the beginning. And Venn diagrams are right enough to start working with joins
  - hinkley 8y ago
    That may be a fair critique. Should SQL be successful only to mathematicians and computer scientists? (Who else would even know about set theory or Venn a priori?)
    - darkpuma 8y ago
      In my underfunded rural American elementary school, they taught us Venn diagrams. Not set theory per-se, but they taught us to read and create Venn diagrams. I don't know if that's representative, but my gut instinct is that Venn diagrams are very accessible to the general public.
- shrimpx 8y ago
  A cross join is the union of 3 mutually exclusive sets: the left join tuples, the inner join tuples, and the right join tuples. Is this not the case? So then you can use Venn diagrams just fine.
  - astine 8y ago
    Um no. The left and right joins both include the inner join tuples; they are not mutually exclusive. A cross join is the Cartesian product of two sets, which means it doesn't include the outer join tuples.
barrkel 8y ago
Venn diagrams are almost, but not quite, completely wrong. They hint at the idea of including failed joins vs only successful joins, but this is only a small part of the full logic behind Cartesian product + filter - even if it's the most commonly used pattern in practice in most database models that ultimately get used in an object oriented programming language. I think it's OK to use the venn diagram only as an explanatory tool, briefly, and informally. If you raise it to the level of a complete description of semantics, then it's very inadequate. Any step off the beaten path, where the cardinality of the join is no longer 1:1 or 1:n, and you're back in the weeds again.

Boxxed 8y ago

Maybe you didn't read the article? He presents a pretty nice visual alternative to Venn diagrams.

obeattie 8y ago
I did read the article and I don't find what the author thinks is a "nice illustration of a cartesian product" easy to grok at all. Similarly, I think I would have found the the diagrams further down hard to understand versus a Venn diagram. But that wasn't my point; if other people find these illustrations helpful, that's awesome and I wouldn't want to stop someone inventing something new and useful. My point was that I violently disagree with one-size-fits-all proclamations like "Say NO to Venn Diagrams."
zzbzq 8y ago
The hardest part of joins is remembering which is which. Venn diagrams are used specifically because they solve that problem with the inner/outer/left/right terminology. His visualizations ultimately help nothing. You have to stare at them for a while to see what the pattern is, but there's absolutely no mnemonic hook to remember what's what, so in the end all you learn from his visualizations are that there exist different ways to slice and dice the products of sets, which is already a given if you're trying to figure out what the differences are.
- 40four 8y ago
  The author's diagrams aren't perfect either, but I think they are much more clear to novice coders about the real workings of joins. Check this out, similar to the author's approach, but animated. This is the best visual of SQL joins I've ever found. https://news.ycombinator.com/item?id=16983007 https://news.ycombinator.com/item?id=16983007
- lloyd-christmas 8y ago
  For me, I still have no idea what the visual of a venn diagram is trying to tell me within the context of SQL. Just having a visual that I can't even understand does nothing to benefit the situation either.

hinkley 8y ago

The thesis is Say no to Venn diagrams for Joins. The first section is about how Venn works fine for AND and OR because it’s set theory and Venn works just fine for examples (maybe not every problem though). Joins are not sets. They are Cartesian products.

y4mi 8y ago
I'll be honest: if I didn't know SQL already, I would have no idea what his diagrams are trying to convey... I do know at this point that he is technically right... But being 100% correct doesn't really matter at the beginning. And Venn diagrams are right enough to start working with joins
- hinkley 8y ago
  That may be a fair critique. Should SQL be successful only to mathematicians and computer scientists? (Who else would even know about set theory or Venn a priori?)
  - darkpuma 8y ago
    In my underfunded rural American elementary school, they taught us Venn diagrams. Not set theory per-se, but they taught us to read and create Venn diagrams. I don't know if that's representative, but my gut instinct is that Venn diagrams are very accessible to the general public.
shrimpx 8y ago
A cross join is the union of 3 mutually exclusive sets: the left join tuples, the inner join tuples, and the right join tuples. Is this not the case? So then you can use Venn diagrams just fine.
- astine 8y ago
  Um no. The left and right joins both include the inner join tuples; they are not mutually exclusive. A cross join is the Cartesian product of two sets, which means it doesn't include the outer join tuples.

barrkel 8y ago

Venn diagrams are almost, but not quite, completely wrong. They hint at the idea of including failed joins vs only successful joins, but this is only a small part of the full logic behind Cartesian product + filter - even if it's the most commonly used pattern in practice in most database models that ultimately get used in an object oriented programming language. I think it's OK to use the venn diagram only as an explanatory tool, briefly, and informally. If you raise it to the level of a complete description of semantics, then it's very inadequate. Any step off the beaten path, where the cardinality of the join is no longer 1:1 or 1:n, and you're back in the weeds again.