September 11, 2012 at 1:44 pm
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?
September 11, 2012 at 2:09 pm
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
September 11, 2012 at 4:09 pm
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
September 11, 2012 at 8:45 pm
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)
_____________
Code for TallyGenerator
September 12, 2012 at 12:38 am
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?
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply