Stuart Davies (3/7/2013)
I'm not dissenting with any previous replies, but personally I would check the results before changing any production code.Try it on a test system with the real table structure, indexes, data etc.
Compare the execution plans (actual not estimated) for your setup and see which is the most efficient.
Don't compare execution plans, compare performance characteristics. You can't tell from a comparison of exec plans which query absolutely will be faster, the costs are estimates, they can easily be wrong.
My general guidelines: Write the query to do just what you want in the simplest way possible, so if you're looking to see if rows match, use exists/in, if you're looking to retrieve columns from both tables, use join. Test the code. If it performs unacceptably under expected load, then go looking for tricks, alternatives and fancy methods
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability