[posted and mailed, please reply in news]
Steve Walker (sw*****@ainet.com) writes:
I've been tasked with "speeding up" a mid-sized production system. It
is riddled with nulls... "IsNull" all over the procs, etc.
Is it worth it to get rid of the nulls and not allow them in the
columns anymore?
Probably not. As Simon said, the columns are likely to be nullable for
a reason.
Then again, I would not be surprised if some columns are nullable only
because of lax design.
It's better to track down slow-running queries, and see how you can
improve them, either by rewriting or better indexing.
Lots of isnull does not have to be bad, but it can be. Take these
two examples:
SELECT col1, col2, col3
FROM tbl
WHERE thiscol = isnull(@par, ' ')
SELECT col1, col2, col3
FROM tbl
WHERE isnull(thiscol, ' ') = isnull(@par, ' ')
The first is OK, and the cost of isnull is likely to be minimal. The
second, however, is potentially bad. This is because, if there is an
index on thiscol, then SQL Server can not seek this index to find
the data. As soon as a column is embedded into an expression, it
is disqualified from index seeks. This is because the index is
organized after the values of the column, not the values of the
expression.
--
Erland Sommarskog, SQL Server MVP,
so****@algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp