Select 1 from...

[clfort09]

Bom dia,

Estou com uma dúvida no SQL agradeço se alguém puder ajudar.

Estou estudando algumas querys sql e vi que em alguns locais tem

SELECT 1 FROM .... (Dentro de uma sub-query)

O que seria isso?


Obrigado desde já.

[SergioLBJr]

Cara geralmente select 1 from.. é pra testar se existe alguma coisa na tabela conforme os parâmetros da query.

Mas só da pra confirmar o porque ele foi usado se tu postar uma query exemplo.

[victorhugomuniz]

é simples como o sergio falou..

considere como uma verificaçao de existencia.. se existe então...

[dr_gori]

Quase sempre o SELECT 1 vem logo após um EXISTS.
Pois o Exists retorna VERDADEIRO caso tenha alguma coisa. E falso se não vier nada.

[SergioLBJr]

Em geral é isso mesmo.

O exemplo mais complexo de entender em um select 1 from é em um report que eu trabalhei onde conforme os parâmetros informados ele adicionava na query do report algo tipo

Selecionar tudo

AND 1 = (select 1 from tabela where ....)

até hoje eu não entendo como a query retornava valores quando o resultado do select 1 era nulo, só sei que funcionava direitinho e que foi desenvolvido desta maneira para melhorar a performance.

[clfort09]

obrigado a todos pela explicação. Agora entendi.

[fsitja]

Quanto a melhorar a performance eu diria que é mito. Mas funcionou está certo.

[victorhugomuniz]

pode se dizer ate que é desprezivel porem tem um tempo na query destino para montagem da saída, logo poderia interferir sim.. mas como disse talvez a interferencia seja desprezivel

[SergioLBJr]

Bom , se realmente melhora a performance da query eu não posso afirmar que sim, pois nunca cheguei a alterar a query para fazer a restrição dos parâmetros de maneira "normal".

Mas é certo que algum motivo para estruturar todo o relatório de maneira diferente dos demais existe, só que como ele foi desenvolvido por pessoas que não mais trabalham na empresa.

Se você souberem alguma diferença

O que é feito é algo assim, eu tenho uma consulta baseado em varias tabelas, os joins entre elas são feito pelas pk's, até aí normal.

Porém ao invés de restringir os campos tipo :

Selecionar tudo

tabela.campo = nvl(:parametro, tabela.campo)

ou....

Selecionar tudo

(:parametro is null or (tabela.campo = :parametro))

como é feito na grande maioria dos relatórios, as restrições são feitas na trigger after parameter form e adicionadas na query como um &parametro.

E são algo tipo :

Selecionar tudo

 (AND 1 = (select 1 from tabela where (algumas restrições que poderiam estar na query) and campo = nvl(:parametro, campo)))

Eu imaginava que ele foi desenvolvido para poder fazer restrições que afetem apenas o resultado do parâmetro e não toda a query do report em si, mas depois me disseram que não.

Se alguém souber por favor posta aí.

[fsitja]

Sem ver um explain plan e um tkprof é difícil de dizer o motivo. Assumindo que as duas queries retornem o mesmo output, mas essa versão é mais rápida, é provável que essa mudança tenha "passado a perna" no CBO, fazendo ele avaliar num plano de acesso com custo menor e coincidentemente com um desempenho superior, com menos consistent gets ou técnicas de join mais adequadas ao que está sendo recuperado.

Não quero dizer que não ficou mais rápido nesse caso, até porque contra fatos não há argumentos, mas sim que esse tipo de solução não é um "macete" secreto do Oracle e que vai implicar numa melhoria de desempenho em outros casos.