Digamos que criamos um procedimento armazenado que possui um parâmetro de entrada opcional.
O SQL entrará em curto-circuito, permitindo que o desempenho dos dois seguintes seja equivalente?
Pergunto porque estou modelando meu próprio proc após o outro, e ele usa o último método. Seria útil saber se isso foi feito por um motivo ou simplesmente porque o autor original não pensou nisso.
select * from
<complex join>
where <various filters>
and (value IS NULL OR myvalue = @value)
OU
if (@value is not null)
begin
select * from
<complex join>
where <various filters>
AND myvalue = @value
end
else
begin
select * from
<complex join>
where <various filters>
end
Geralmente, o SQL é declarativo. Ou seja, você diz "o que você quer" e não "como fazer". Uma consequência disso é que você não controla em que ordem as coisas são processadas ou avaliadas na mesma etapa de processamento lógico (cláusula WHERE ou cláusula GROUP BY, etc., são essas etapas)
Ou seja, o SQL geralmente não causa um curto-circuito porque o conceito não se aplica.
Existem vários casos em que isso ocorre (SQL Server e CASE, por exemplo), é claro, mas no seu exemplo você precisaria da 2ª opção para garantir isso. Observação O SQL Server tem uma otimização para esse tipo de consulta, mas presumo que o Sybase não