Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Not in clause vs list of <> Expand / Collapse
Author
Message
Posted Tuesday, September 11, 2012 1:44 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, September 30, 2014 11:50 AM
Points: 24, 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?


Post #1357674
Posted Tuesday, September 11, 2012 2:09 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 13,872, Visits: 9,596
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
Post #1357686
Posted Tuesday, September 11, 2012 4:09 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 40,154, Visits: 36,541
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 2008, MVP
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

Post #1357735
Posted Tuesday, September 11, 2012 8:45 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Monday, October 13, 2014 8:08 PM
Points: 4,573, Visits: 8,353
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)

Post #1357769
Posted Wednesday, September 12, 2012 12:38 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, September 30, 2014 11:50 AM
Points: 24, 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?
Post #1357802
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse