: Usar JOIN ou condicão WHERE

[rdgomes 0]

Oi.Gostaria que ai a galera me respondesse a uma dúvida.Na junção de tabelas eu uso a condição WHERE, do género:Tabelas:cidade(id_cidade, nome_cidade, id_pais)pais(id_pais, nome_pais)SQL:SELECT cidade.nome_cidade, pais.nome_pais FROM cidade, pais WHERE pais.id_pais=cidade.id_paisSerá esta a melhor opção, ou devo usar o INNER JOIN? Como faço para relacionar as duas tabelas?

[Kandrade 7]

Será esta a melhor opção, ou devo usar o INNER JOIN?

Usando INNER JOIN seu sql fica mais elegante. Eu procurei saber se JOIN tem melhor desempenho, mas não encontrei.De fato voce usar WHERE ou INNER JOIN o resultado é o mesmo.Vamos esperar as resposta dos colegas mais experientes.

Como faço para relacionar as duas tabelas

Voce irá informar as duas tabelas e o ponto de junção entre elas.

SELECT cidade.nome_cidade, pais.nome_pais FROM cidade INNER JOIN pais ON pais.id_pais=cidade.id_pais

http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

[Wagner Bianchi 0]

Olá pessoal,

 

De fato, as duas opções são relevantemente legais! Vamos comentar um pouco sobre isso?

 

O que acontece quando uma consulta SELECT chega ao analisador de consultas em qualquer SGBD?

 

Quando uma consulta chega a este componente que em cada SGBD existe um, pode ser o "Cache de Biblioteca" de ORACLE, pode ser o analisador do SQL Server, do MySQL ou de qualquer outro; de fato o primeiro acontecimento é, separar um query com JOIN em conjuntos que geralmente ganham identificadores como 1k2j3gh1kj32hg41kj2h3g4j1hg234jh1g, ou seja, um hash, que identifica aquele conjunto único. Após selecionar o conjunto A, B e C, o analisador olha para o tipo de junção que foi enviado, se LEFT, RIGHT, INNER, FULL, NATURAL, STRAIGHT, CROSS ou APPLY.

 

No caso aqui deste tópico, o analisador logo perceberá que enviamos um INNER JOIN, então ele seleciona todas as correpondências entre os conjuntos, ou seja, tudo o que está relacionado.

 

Quando é detectada uma junção feita através do WHERE, ele recolhe os conjuntos, A, B e C e seleciona registros ONDE (WHERE) a condição é satifeita, ou seja, onde há registros relacionados!!!

 

O MODELO RELACIONAL É FANTÁSTICO!!

 

Abraço pessoal!! http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

[Kandrade 7]

Boa!!! esclareu bem como funciona cada uma.Tenho algumas dúvidas:A projecão dos dados pelo que me recordo é feita depois da selecão. Correto?No caso do JOIN só depois que o banco fez a correspondencia.

No caso aqui deste tópico, o analisador logo perceberá que enviamos um INNER JOIN, então ele seleciona todas as correpondências entre os conjuntos, ou seja, tudo o que está relacionado.

A dúvida é:Qual é o conteúdo dos conjuntos quando são separados?Somente os campos que fazem a juncão? :mellow:

[Wagner Bianchi 0]

Bom vamos lá. . .papo de cientista hein??!?!?, me agrada muito!!

 

Seguinte, quando uma consulta então chega ao analisador ou "parseador" da linguagem sql e dá um ok, tudo correto com a sintaxe, é hora de ver o que o usuário deseja. Falando em álgebra relacional, neste momento, após o parse, o banco de dados realmente fará o projeto do que ele retornará, pois o *parse em si também valida a existência dos objetos passados na consulta, caso algum deles não exista, PAU!!

 

Após projetar, vamos definir como apanhar os dados, sendo que, eu crio dois conjuntos A e B, dessa forma:

 

=> CONJUNTO tbl_turma;

=> CONJUNTO tbl_aluno;

 

No momento eu tenho todas as turmas e todos os alunos que, por via não estão no disco e sim na? na? na?...isso mesmo, nas páginas de dados ou blocos que se encontram na memória, BINGO!! Por isso a coisa é rápida!! Putzzz, matamos a pau! Continuando, vamos ver agora o que é comum nos dois conjuntos, no caso do INNER ou o que não tem relação de A => B (LEFT) ou o que não tem relação de A <= B (RIGHT), OK?

 

Conseguimos??

 

Ahhh, os campos que você determina na sua seleção, são filtrados do resultado.

 

Agora uma coisa bacana, vamos supor que nesse momento, nós que somos o "carinha" componente que entregaremos o resultado para o usuário cliente que solicitou os dados. Suponha que nesse momento ele muda a consulta e envia para nós um INNER JOIN com um operador LIKE e uma cláusula ORDER BY!!! Eu fiquei cansado, essa vida de analisador e parseador de consulta não é para mim!! ehehehe

 

Quer agaxar um SGBD, consumindo bastante seus recursos? Use LIKE, INNER JOIN, ORDER BY, COUNT(*) e SubQueries!! ehehe

 

Agaxar pois estes operadores, funções e cláusulas exigem muito do SGBD! Um ORDER BY tem até uma área chamada de "área de classificação" para fazer o "sort" dos dados temporariamente. Consultas grandes agaxam mesmo nesse caso!

 

Abração meu camarada Kandrade e atodos que partipam deste tópico!! Qualquer coisa, continue o post pois esse assunto é bom cara, eu curto d+!!

Falar de maquinaria de SGBD`s! :rolleyes:

 

http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

 

Parse: é a interpretação do código, qualquer linguagem interpretada tem um parseador para transformar a linguagem de alto nível (linguagem para seres humanos) em linguagem de máquina, ou seja, linguagem de baixo nível.

[webruno 0]

Olá Wagner... sei que o tópico é meio antigo, mas precisei fazer uma busca pelo INNER JOIN e achei esse tópico que me deixou intrigado.O que você quis dizer no post a cima com:"Quer agaxar um SGBD, consumindo bastante seus recursos? Use LIKE, INNER JOIN, ORDER BY, COUNT(*) e SubQueries!! ehehe"Queria relacionar 3 tabelas com o INNER JOIN e li alguns comentários que não tem diferença entre o WHERE e o INNER JOIN.Com esse comentário você quis dizer que é melhor usar apenas o WHERE já que o INNER JOIN "agaxa" o SGBD?To certo ou viajei nessa?

[Wagner Bianchi 0]

Não, não viajou e há pouca diferença entre os dois, mas que com uma quantidade grande de tabelas e dados pode ser uma boa diferença.

Pense em dois conjunto, A e B, quando eu tenho que pegar os elemntos de A mais os elementos de B e depois selecionar suas correspondências, estou fazendo um INNER JOIN. Mas, quando eu já seleciono o A e B querendo A = B, já trago os registros relacionados, esse é o WHERE. Boa?

 

Pequenas consultas com poucos dados, use o que melhor lhe convier. http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

 

Abração!! http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

[webruno 0]

humm, pode cre... entendi!Só vou de WHERE agora, hehe.Valeu.

[Wagner Bianchi 0]

Pessoal,

 

Uma ressalva que quero fazer de toda essa explicação é que, tudo que foi explanado aqui destas condioções de busca, dependerá também da posição dos ínidices. O MySQL dispõe de uma declaração especial EXPLAIN para que nos permite verificar facilmente o que o SGBD teve que fazer para recuperar os dados de uma consulta sofisticada, utilizando JOIN ou WHERE, segue o exeplo, e façam os testes:

 

EXPLAIN <sua_consulta_aqui>;

 

O resultado será algo como isso:

 

*************************** 1. row ***************************

 

id: 1

 

select_type: SIMPLE

 

table: CountryList

 

type: ALL

 

possible_keys: NULL

 

key: NULL

 

key_len: NULL

 

ref: NULL

 

rows: 239

 

Extra:

 

*************************** 2. row ***************************

 

id: 1

 

select_type: SIMPLE

 

table: CityList

 

type: ALL

 

possible_keys: NULL

 

key: NULL

 

key_len: NULL

 

ref: NULL

 

rows: 4079

 

Extra: Using where

 

...cada coluna e o que ela representa pode ser verificado neste link: http://dev.mysql.com/doc/refman/5.0/en/explain.html

 

Abração a todos!! http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif