OR or IN

Question

OR or IN

Viewing 3 posts - 16 through 18 (of 18 total)

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

Steve Jones - SSC Editor SSC Guru Points: 738609 More actions · Answer 1

sorry to be late getting back, but I think IN reads better, especially when other people will see the code. Easy to make mistakes with OR.

If someone says OR is better in an interview, I'd agree to disagree. My thoughts are they are the same.

the functional descriptions in BOL seem to indicate they work the same. There could potentially be a shortcut for the query optimizer if you knew that some data was likely to occur and put that first in an OR condition, but I would think putting it first in an IN condition would do the same thing.

GSquared SSC Guru Points: 260824 More actions · Answer 2

Steve Jones - Editor (5/20/2008)
sorry to be late getting back, but I think IN reads better, especially when other people will see the code. Easy to make mistakes with OR.
If someone says OR is better in an interview, I'd agree to disagree. My thoughts are they are the same.
the functional descriptions in BOL seem to indicate they work the same. There could potentially be a shortcut for the query optimizer if you knew that some data was likely to occur and put that first in an OR condition, but I would think putting it first in an IN condition would do the same thing.

The database will generally ignore the sequence and go with the statistics anyway. And since it will all result in index/table scans anyway, the sequence won't matter much if at all.

- 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

Jeff Moden SSC Guru Points: 1004635 More actions · Answer 3

If you're going to do it more than once in the same proc, make a temp table and join to it because IN, OR, and INNER JOIN are pretty much the same. Side benefit will be to allow you to change all the code from a single point should the requirements ever change.

--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)