codegumbo » Wh… on [blog] What Should PASS Be?… If PASS Closed Its D… on [blog] What Should PASS Be?…
If you have experience with joining the military then thank you sir or ma’am but as a SQL Server DBA you are sure to have experience with joining tables using Transact-SQL. My first blog post was on this exact same subject and this post will be a condensed version of it, SQL Server Joins using Playing Cards There are three primary JOIN operators the Query Optimizer will pick from: Nested Loops, Merge Join and Hash Match.
Imagine you were asked to find all the Aces in a deck of cards. How would you accomplish that? You would probably flip them all over and scan across them looking for the Aces. You would likely do the same if you were told that this would repeat for three, four or five different ranks. What if you were told it would be for eleven, twelve or even all thirteen different ranks?
If you were going to match many different ranks then you would probably decide scanning would be too repetitive. Instead you might break the deck into a pile for each rank. The time it took to reorganize the cards will be made-up by not having to look at every single card when another rank is asked for. What if you were told to match all fifty-two cards one-to-one between two decks?
We need to take a small leap of faith to continue using this card matching analogy. For now image that you have the ability to perform a perfect shuffle, where exactly one card from each the left and the right stacks fall together through-out the entire shuffle. If you had to find all fifty-two card matches you would likely go with a Hash Match but now that you are bestowed with the gift of Perfect Shuffle you have a better option. You quickly sort each deck then perform a perfect shuffle and BAM! The analogy is more appreciable when the cards are already sorted or the number of them is much higher than fifty-two.