SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Not in clause vs list of <>


Not in clause vs list of <>

Author
Message
HooRoo
HooRoo
SSC Rookie
SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)

Group: General Forum Members
Points: 40 Visits: 116
Taking the examples:

EXAMPLE A
Select AColumn
from ATable
where AnotherColumn not in(1,2,3)

VS

EXAMPLE B
Select AColumn
from ATable
where AnotherColumn <> 1
and AnotherColumn <> 2
and AnotherColumn <> 3

Apart from the obvious advantage that A involves less typing
- what are the advantages/disadvantages (if any) of one over the other?

My assumption that A is has better performance is apparently(sadly) incorrect
(they have proven to be about the same).

My colleague is under the impression that A is simply translated into B by the database anyway,
so insists that B is preferable. I can't seem to find any evidence of that though.

Can anyone confirm/deny, suggest pros/cons or further reading for either method?
GSquared
GSquared
SSC Guru
SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)

Group: General Forum Members
Points: 94829 Visits: 9730
A and B are equivalent under the hood. Your friend is correct that they work the same way. You can usually see that if you look at the execution plan for each of these.

As for which way to write it, I prefer Not In, simply because I find it more readable. That's purely an opinion/preference, with no solid reason behind it. In a simple query like your sample, the readability won't matter. In more complex queries, tracing out all the And and Or operations in a Where clause can be a huge pain, and splitting it up makes that more difficult, not less.

I've seen many queries get wrong results because of incorrect relationships between various And/Or operations, misplaced parentheses, etc. Readability makes a huge difference in how easy they are to debug. Since there's zero mechanical difference between the two, I pick the readable one.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
GilaMonster
GilaMonster
SSC Guru
SSC Guru (371K reputation)SSC Guru (371K reputation)SSC Guru (371K reputation)SSC Guru (371K reputation)SSC Guru (371K reputation)SSC Guru (371K reputation)SSC Guru (371K reputation)SSC Guru (371K reputation)

Group: General Forum Members
Points: 371084 Visits: 46968
HooRoo (9/11/2012)
My colleague is under the impression that A is simply translated into B by the database anyway,
so insists that B is preferable.


He's correct that A is translated into B as part of the parsing. His conclusion that it's preferred however does not follow from that premise.

They are identical, the parse to the same internal structure, so you can use whichever you prefer (and I'd prefer the first as it's a hell of a lot easier to read)

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Sergiy
Sergiy
SSC-Forever
SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)

Group: General Forum Members
Points: 40245 Visits: 12605
Actually hardcoding business rules is an extremely bad practice.
So, none of the options is preferrable.
(do I sound like you know who? ;-) )

If you follow the proper DB modelling rules you put the values into a lookup table and then you get to the really preferrable approach:

Select AColumn
from ATable A
where not exists (
select * from LookupTable L
where A.AnotherColumn=L.ExcludedValue)


HooRoo
HooRoo
SSC Rookie
SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)

Group: General Forum Members
Points: 40 Visits: 116
Thank you all for your insights!
I suspect that my colleague and I have reached a 'syntax impasse' on this one.

And whilst ordinarily I would agree SSCarpel Tunnel
- in this instance we are excluding specific transaction types, (so even in a 'not exists')
would we not have to bolt on the list of excluded codes?
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search