Gostaria de saber, quando ao SGBD ORACLE, qual a diferença entre fazer:
select CAD.CIF, CAD.VENCTO_FATURA from
CADCTRL CAD INNER JOIN MAPA_CICLOS MAPA ON
CAD.CICLO = MAPA.CICLO
ORDER BY MAPA.DIA_VENCIMENTO
e
select CAD.ID, CAD.VENCTO_FATURA from
CADCTRL CAD, MAPA_CICLOS MAPA
WHERE CAD.CICLO = MAPA.CICLO
ORDER BY MAPA.DIA_VENCIMENTO
Estou fazendo uma priorização com base no dia do vencimento que há em outra tabela MAPA_CICLOS.
Em termos de desempenho, qual é a melhor maneira?
Pelo que sei, a diferença de desempenho é zero.
Os SGDBs atuais se adaptaram à prática dos desenvolvedores de colocar joins dentro da cláusula WHERE, e produzem o mesmo plano de execução de uma query similar com JOIN explícita.
Apesar que, na minha opinião, acho triste as pessoas só saberem usar usar junção dentro de WHERE, pois acho cláusulas JOIN mais legíveis.
Se o otimizador estiver em perfeito funcionamento a diferença de desempenho deve ser zero…
E diferente do Leonardo3001, eu acho os WHEREs mais legíveis que os JOINs, pelo menos no oracle, que suporta o uso do operador (+) para left e rigth join 
O único problema é ter de ficar traduzindo isso em uma posterior migração, se houver…
Eu só uso join, pois dependendo da query te traz resultados diferentes. Relacionamento opte sempre usar o join pois, ele verifica as condições antes do que uma query sem join e com as condições no where.
Quando estamos falando de nível empresarial há diferença sim, mesmo que seja 1 seg, isso é importante na hora de retornar um resultado para o cliente. Agora uma tabela com 5 mil registros, 10 mil dependendo do seu hardware a diferença vai para os milisegundos.
Experimente popular 2 tabelas com dezenas de milhares de registros e faça as 2 querys que vc vai ver a diferença de tempo. A nível empresarial é normal ter tabelas com esse tamanho.
Com poucas tabelas, diferença de desempenho próxima do zero.
Mas com muitas tabelas, entendo que com o Join voce já define
a melhor pesquisa, não deixando esta tarefa para o banco,
o que seria usando o where.
O join é mais profissional, na minha opinião.
Bom dia
Eu sempre usei inner join para realizar junções entre tabelas, mas também já peguei querys onde os relacionamentos eram feitos no where, eu te aconselho a usar inner join, pois para uma possivel análise da query em manutençãoes futuras, acredito que fica bem mais legivel e fácil de entender os relacionamentos.
Falou.
[quote=Leonardo3001]Pelo que sei, a diferença de desempenho é zero.
Os SGDBs atuais se adaptaram à prática dos desenvolvedores de colocar joins dentro da cláusula WHERE, e produzem o mesmo plano de execução de uma query similar com JOIN explícita.
Apesar que, na minha opinião, acho triste as pessoas só saberem usar usar junção dentro de WHERE, pois acho cláusulas JOIN mais legíveis.
[/quote]
Entendo. Para mim Leonardo, eu sei fazer das duas formas e sei que as pessoas se habituaram mais com a junção dentro do WHERE.
Eu acho melhor fazer o Join explícito para controlar o retorno da segunda tabela “juntada” com mais clareza (como definir se só deve voltar registros se a chave existir em ambas as tabelas ou retornar de todos da primeira, independente disso, o que sei que pode-se fazer com palavras reservadas em conjunto com o JOIN.
O que fiquei na dúvida é quanto ao desempenho…
obrigado!
[quote=rjdiogo]Eu só uso join, pois dependendo da query te traz resultados diferentes. Relacionamento opte sempre usar o join pois, ele verifica as condições antes do que uma query sem join e com as condições no where.
Quando estamos falando de nível empresarial há diferença sim, mesmo que seja 1 seg, isso é importante na hora de retornar um resultado para o cliente. Agora uma tabela com 5 mil registros, 10 mil dependendo do seu hardware a diferença vai para os milisegundos.
Experimente popular 2 tabelas com dezenas de milhares de registros e faça as 2 querys que vc vai ver a diferença de tempo. A nível empresarial é normal ter tabelas com esse tamanho.[/quote]
Concordo plenamente. Com poucos registros não se vê diferença. Mas como estou trabalhando com milhares de registros, que terão taxa de crescimento de ~5000 registros por dia… depois de algum tempo, serão milhões, 10 milhões…, é aí que vão aparecer as diferenças entre aqueles “milissegundos” iniciais…
Em um consulta com múltiplos JOINS, por exemplo, que rodava em um hora, ganhei 30 mintuos omitindo o ORDER que não era necessário ali.
Qualquer ganho de desempenho obtido no começo, com poucos registros, refletirá no resultado futuro com volumes maciços de dados.
[quote=diego_qmota]Gostaria de saber, quando ao SGBD ORACLE, qual a diferença entre fazer:
select CAD.CIF, CAD.VENCTO_FATURA from
CADCTRL CAD INNER JOIN MAPA_CICLOS MAPA ON
CAD.CICLO = MAPA.CICLO
ORDER BY MAPA.DIA_VENCIMENTO
e
select CAD.ID, CAD.VENCTO_FATURA from
CADCTRL CAD, MAPA_CICLOS MAPA
WHERE CAD.CICLO = MAPA.CICLO
ORDER BY MAPA.DIA_VENCIMENTO
Estou fazendo uma priorização com base no dia do vencimento que há em outra tabela MAPA_CICLOS.
Em termos de desempenho, qual é a melhor maneira?[/quote]
A forma com Join explicito é sempre melhor. não pelo desempenho mas pela legibilidade. É a forma padrão.
Em alguns bancos pode haver diferença de performance, mas a performance com JOIN sempre será igual ou maior que sem, logo, não ha razão alguma para não usar join explicito.
O que vale, na hora de medir o desempenho, é o plano de execução (ou no mundo Oracle: “explain plain”). A minha argumentação é que as duas queries, citadas por você, produzem o mesmo plano; logo, você não vai ter ganho nenhum de desempenho trocando uma pela outra (não importa se você vai ter 5000 registros, a argumentação do pessoal de que você vai ter ganho de alguns décimos de segundo, pra esse caso, não procede).
Pra você otimizar, só olhando o explain plain de uma massa de dados bem grande, e removendo possíveis “full table scan” (busca pelos registros de uma tabela inteira sem índice).
Lembrando que, muito melhor que decidir entre plano cartesiano ou cláusula Join, é fazer a decisão correta quanto aos seus índices e a normalização dos dados.
Índices nas colunas corretas e usando o tipo de índice correto (bitmap index, b-tree index etc) fazem MUITA diferença, ainda mais em Joins, onde normalmente se faz o relacionamento de tabelas inteiras, navegando de registro em registro.