no more blogging at this site as I begin learning the ropes as a new postgresql dba. cheers!
Wednesday Weekly #sqlserver Links 
Grab a plate and load it up.
Joining
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?
Merge Join
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.
See Also
Physical Join Operators in SQL Server – Nested Loops – SQL Server Performance
Physical Join Operators in SQL Server – Hash Operator – SQL Server Performance
Physical Join Operators in SQL Server – Merge Operator – SQL Server Performance
Nested Loops Join – Craig Freedman’s SQL Server Blog – Site Home – MSDN Blogs
Hash Join – Craig Freedman’s SQL Server Blog – Site Home – MSDN Blogs
Merge Join – Craig Freedman’s SQL Server Blog – Site Home – MSDN Blogs
People
Wednesday Weekly #sqlserver Links
Help yourself to this link feast.
Wednesday Weekly #sqlserver Links
Here are some yummy links from this week.
Wednesday Weekly #sqlserver Links
Biggest SQL Server feast to date so be sure to come back for seconds.
T-SQL Tuesday
Robert Pearl has heeded the call of hosting the T-SQL Tuesday blog party this month. Please click on the #tsql2day image above to learn more about why the topic is “data-presentation”. If you want to read more party-style blog posts then also check out the summary by Adam Machanic called A Year of Tuesdays: T-SQL Tuesday Meta-Roundup.
Presents
Who presents the data to your users? There are occasions when the DBA will be asked to write T-SQL for Manipulating Result Sets. Mr. Pearl mentioned having experience with Using Common Table Expressions in the invitation. I had a similar experience with Using GROUP BY with ROLLUP, CUBE, and GROUPING SETS. Who should present data to the users? Although this blog party has T-SQL in the title this post will be more theoretical than practical.
Tiers
There are always exceptions to any rule but as a general rule I subscribe to the N-Tier / Multi-tier architecting of applications. There are entire books about the benefits but for the sake of a short post I would like to share just two benefits of this architecture for a DBA. If you plan to stay for the soapboxing then please take a minute and look over this diagram by Damon Armstrong on Multi-tier architecture from his post .NET Application Architecture: the Data Access Layer.
Tools
Transact-SQL and SQL Server are used to scatter and gather data. CLR and Business Objects are used for control flow logic. Windows Presentation Foundation and Forms/Controls are used for user interface presentation. Each is a great tool for performing their intended task. You have NEVER used a crescent wrench as a hammer right? In the same tongue in cheek tone, you such NEVER use T-SQL to figure out the next user product suggestion and NEVER use T-SQL to display a dollar sign on the right side of a number.
Really?
Let us pretend that you inherited a stored procedure that does format the output so that there is a dollar sign displayed on the right side of a number. Who do you suppose would be tasked if the user wanted a different format? (Euros, two decimal places, in millions, negatives in parenthesis) Each of these has the potential to become a major time suck and also cause some wicked stored procedure sprawl. It has happened, it is still happening and will probably continue to happen but hopefully you are better informed for avoiding the problem.
People
Welcome to the show
sqlmashup 