2
SELECT * FROM tableName WHERE (ISNULL(columnName,0) > 0)

OR

SELECT * FROM tableName WHERE (columnName IS NOT NULL) AND (columnName > 0)

which one is better?

columnName has int datatype

IsmailS
  • 10,797
  • 21
  • 82
  • 134
  • Why don't you have a look using the SQL Query Analyzer? – Gnat Dec 16 '11 at 13:45
  • 3
    You should understand that a NULL value compared to 0 will never return True, so you don't need to check for it. You should also know that, unless the Optimizer is smart enough to fix this for you, ISNULL(columnName,0)>0 will not be able to take advantage of an index on your column. So, that would be an advantage of the second form, if you needed the comparison to NULL (which you don't). – GilM Dec 16 '11 at 15:01
  • I reckon @GilM has the best answer. Making sure your queries take advantage of indexes (sargeable) can be pretty important. – Fionnuala Dec 16 '11 at 16:22

3 Answers3

7

You don't need to check for null values in your query so I guess this would be better.

SELECT * FROM tableName WHERE columnName > 0
Mikael Eriksson
  • 136,425
  • 22
  • 210
  • 281
3

And why not just WHERE columnName > 0 ? The rest of the condition is seems redundant: Nulls will not be returned.

iDevlop
  • 24,841
  • 11
  • 90
  • 149
0

Better how?

I think the latter is more readable, others may disagree. You may have a house style that favours the former in which case there is no question.

As to performance, well I very much doubt either is causing a performance issue so you shouldn't optimise, premature optimisation is the root of all evil.


Here is a good question asking When is optimisation premature? and here is a definition of the term.

In this case the performance improves roughly in this order:

SELECT Count(*) FROM BigTable WHERE (ISNULL(SmallNumber,0) > 0) --140 ms
SELECT Count(*) FROM BigTable WHERE (SmallNumber IS NOT NULL) AND (SmallNumber > 0) --41 ms
SELECT Count(*) FROM BigTable WHERE SmallNumber > 0 --30 ms

But swap Count(*) with * and any tiny performance gain is lost in a sea for retrieving rows.

You can test it yourself after using this ugly lump of code to create a big table.

CREATE TABLE [dbo].[BigTable]( [ID] [int] IDENTITY(1,1) NOT NULL, [BigNumber] [bigint] NULL, [SmallNumber] [int] NULL,
    CONSTRAINT [PK_BigTable] PRIMARY KEY CLUSTERED ( [ID] ASC ));
CREATE NONCLUSTERED INDEX [IX_BigTable] ON [dbo].[BigTable] ([SmallNumber] ASC);
With Digits as ( SELECT 0 AS d UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 
    UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9),
OneToAMillion as (SELECT (100000 * D6.d) + (10000 * D5.d) + (1000 * D4.d) + (100 * D3.d) + (10 * D2.d) + (1 * D1.d) AS Number
    FROM Digits D6, Digits D5, Digits D4, Digits D3, Digits D2, Digits D1)
INSERT INTO dbo.BigTable (BigNumber, SmallNumber) SELECT CAST(CHECKSUM(NEWID()) as BigInt) * CHECKSUM(NEWID()), CHECKSUM(NEWID()) FROM OneToAMillion;
UPDATE BigTable SET SmallNumber = Null WHERE BigNumber < 0;
Community
  • 1
  • 1
Stephen Turner
  • 7,125
  • 4
  • 51
  • 68
  • 3
    -1 Nonsense. Avoiding non sargable expressions is not a case of premature optimisation. – Martin Smith Dec 16 '11 at 18:02
  • I firmly believe you are wrong. Even if the program was slow, the optimisation in the original question would affect readability more than performance. (edited answer with tests) – Stephen Turner Dec 16 '11 at 19:45
  • 1
    Agree with Martin Smith. Sargability is just a best practice. You are only taking into account runtime. I've used this technique to get 1000x improvement on select queries written by someone not understanding the concept. – Anon246 Dec 16 '11 at 21:22
  • Your 1000x improvement falls into the "3% of opportunities that should not be passed up" and in that case sargable query was key, but this question doesn't even mention indexes. – Stephen Turner Dec 16 '11 at 21:47
  • 1
    While I agree that it always depends somewhat on the situation (how much is performance an issue, how often is this called, how much time and complexity does the enhancement cost...etc.), I also think cultivating good habits prevents a lot of problems, and using forms that are SARG friendly when crafting WHERE clauses is one of those good habits that should not be discouraged. It's definitely not the root of all evil. It's not even bad. It's good. – GilM Dec 17 '11 at 00:17