Mar 282014
 

Joins appear (to me) to be getting a lot of bad press recently. In discussions I’ve had and articles I’ve read many give the position that joins are somehow inherently bad and to be avoided at all costs.

I’ve never been entirely convinced by the “joins are bad” arguments however. Partly because there’s few concrete cases actually demonstrating the (additional) cost of joins. Instead discussions tend to be hand-wavy arguments around extra CPU cycles used or something to that effect.

So over the next few posts I’m going to do something a bit different on this blog and discuss joins in more detail. We’ll ask questions like:

  • Does removing joins (denormalizing) really help performance? If so, what are the catches?
  • When are joins bad? What can be done in these cases?

If you’ve got any other questions around joins let me know – I’ll add them to the list and address them in this series.

  3 Responses to “In Defense of Joins”

  1. Hi Chris,

    maybe one reason for the bad press is MySQL (used in many NoSQL projects) where the only existing join operation is Nested Loops (no Hash Join, no Merge Join) – and if I only had NL joins then I would also try to avoid joins with bigger sets…

    • I think you’re right with that Martin – certainly “larger” joins would suffer if restricted to just nested loops. I think this is spreading from (certain) joins are bad (in mySQL) to all joins are bad in all databases!

  2. […] the past few articles we’ve looked at database joins. It started out with me noticing that joins appear to be getting bad press recently and wondering whether they […]

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>