2

私はストアド プロシージャに重きを置く SQL Server 環境で作業しており、多くのプロシージャが Null の代わりに 0 と '' を使用して、意味のあるパラメータ値が渡されなかったことを示しています。

これらのパラメーターは、WHERE 句で頻繁に使用されます。通常のパターンは次のようなものです

WHERE  ISNULL(SomeField,'') = 
    CASE @SomeParameter 
        WHEN ''  THEN ISNULL(SomeField,'')
        ELSE @SomeParameter
    END

さまざまな理由から、proc を呼び出すコードを変更するよりも、proc を変更する方がはるかに簡単です。では、呼び出し元のコードが null パラメーターに対して空の文字列を渡すことを考えると、空の文字列と比較する最も速い方法は何ですか?

私が考えたいくつかの方法：

@SomeParameter = ''

NULLIF(@SomeParameter,'') IS NULL

LEN(@SomeParameter) = 0

また、proc の早い段階でパラメーターを検査し、'' に等しい場合は NULL に設定し@SomeParameter IS NULL、実際の WHERE 句でテストを行うことも検討しました。

他にどのような方法がありますか？そして、何が最速ですか？

どうもありがとう。

4

1 に答える 1

1

proc の開始時にパラメーターを並べ替えるのは、where 句で複数の条件を使用したり、1 つの関数を使用したりするよりも高速である必要があります。クエリが複雑であるほど、またはフィルター処理する必要があるレコードが多いほど、メリットが大きくなります。

私を怖がらせるのは、プロシージャの引数に null 可能性がないことがデータにも影響を与えている場合です。ロックダウンを開始したときにそうである場合、クエリは「間違った」結果で返されます。

この製品にある程度の寿命がある場合、長期的には簡単なソリューションは間違ったソリューションであり、呼び出し元のアプリケーションで修正する必要があると言えます。そうでない場合は、敷物の下、別の敷物の下から混乱を一掃するだけなので、そのままにしておく必要があるかもしれません...

これらの変更をどのようにテストするつもりですか。同じ変更を何度も何度も何度も何度も何度も繰り返すことで頭が疲れている間に、わずかなエラーが発生する可能性が非常に高くなります。

于 2012-09-20T22:40:25.050 に答える