Which is Better?

Question

Which is Better?

AndrewSQLDBA

SSC-Insane

Points: 21827
More actions
April 14, 2014 at 8:56 am

#306476

Hello Everyone
I am reviewing code in a SQL database that was coded by a BA and a Old oracle developer. Never a good idea to begin with. I am finding a lot of queries that should be using a JOIN, or LEFT OUTER JOIN, and they are using sub-queries with NOT IN. Plus s lot of just poorly written code.
I am looking for some solid proof as to which type of query is better. I have always known that using JOIN is always better for performance since one can index that column(s) that the JOIN will use. Which is usually a Primary key in the tables involved.
Can someone shed some light on this.
Thank you in advance for all your advice, suggestions and time.
Andrew SQLDBA

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Keith Tate SSCrazy Eights Points: 9938 More actions · Answer 1

Aaron Bertrand has a great article on this topic http://www.sqlperformance.com/2012/12/t-sql-queries/left-anti-semi-join

Microsoft Certified Master - SQL Server 2008
Follow me on twitter: @keith_tate

Forum Etiquette: How to post data/code on a forum to get the best help[/url]

Jeff Moden SSC Guru Points: 1004363 More actions · Answer 2

AndrewSQLDBA (4/14/2014)
Hello Everyone
I am reviewing code in a SQL database that was coded by a BA and a Old oracle developer. Never a good idea to begin with. I am finding a lot of queries that should be using a JOIN, or LEFT OUTER JOIN, and they are using sub-queries with NOT IN. Plus s lot of just poorly written code.
I am looking for some solid proof as to which type of query is better. I have always known that using JOIN is always better for performance since one can index that column(s) that the JOIN will use. Which is usually a Primary key in the tables involved.
Can someone shed some light on this.
Thank you in advance for all your advice, suggestions and time.
Andrew SQLDBA

To be honest, IN and NOT IN are actually a little bit faster than the related joins. There are some caveates for both that people need to understand. NOT IN can actually be a fair bit faster than an OUTER JOIN with a predicate that looks for NULLs.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

AndrewSQLDBA SSC-Insane Points: 21827 More actions · Answer 3

Thank you to you both.

I read the article, that is a very good one.

Thanks again

Andrew SQLDBA

Jeff Moden SSC Guru Points: 1004363 More actions · Answer 4

Here's another excellent link on the subject. The article also has other links. Gail Shaw is a Microsoft Certified Master and she has put together quite the writeup on these subjects including some of the caveates of using one vs another.

http://sqlinthewild.co.za/index.php/2010/02/18/not-exists-vs-not-in/

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)