Em consultas MySQL, por que usar join em vez de onde?


108

Parece que combina duas ou mais tabelas, podemos usar join ou where. Quais são as vantagens de um sobre o outro?


2
Dependendo de seu uso, possivelmente tem os mesmos resultados, mas com um JOIN você pode fazer outros tipos de associações.
zneak de

Isso responde sua pergunta? Cláusula INNER JOIN ON vs WHERE
philipxy

Respostas:


160

Qualquer consulta envolvendo mais de uma tabela requer alguma forma de associação para vincular os resultados da tabela "A" à tabela "B". O meio tradicional (ANSI-89) de fazer isso é:

  1. Liste as tabelas envolvidas em uma lista separada por vírgulas na cláusula FROM
  2. Escreva a associação entre as tabelas na cláusula WHERE

    SELECT *
      FROM TABLE_A a,
           TABLE_B b
     WHERE a.id = b.id

Aqui está a consulta reescrita usando a sintaxe ANSI-92 JOIN:

SELECT *
  FROM TABLE_A a
  JOIN TABLE_B b ON b.id = a.id

De uma perspectiva de desempenho:


Onde houver suporte (Oracle 9i +, PostgreSQL 7.2+, MySQL 3.23+, SQL Server 2000+), não há benefício de desempenho em usar uma das sintaxes sobre a outra. O otimizador os vê como a mesma consulta. Porém, consultas mais complexas podem se beneficiar do uso da sintaxe ANSI-92:

  • Capacidade de controlar a ordem de JOIN - a ordem em que as tabelas são verificadas
  • Capacidade de aplicar critérios de filtro em uma tabela antes de ingressar

De uma perspectiva de manutenção:


Existem vários motivos para usar a sintaxe ANSI-92 JOIN em vez de ANSI-89:

  • Mais legível, pois os critérios JOIN são separados da cláusula WHERE
  • Menos probabilidade de perder os critérios JOIN
  • Suporte de sintaxe consistente para tipos de JOIN diferentes de INNER, tornando as consultas fáceis de usar em outros bancos de dados
  • A cláusula WHERE serve apenas como filtragem do produto cartesiano das tabelas reunidas

De uma perspectiva de design:


A sintaxe ANSI-92 JOIN é padrão, não anti-padrão:

  • O objetivo da consulta é mais óbvio; as colunas usadas pelo aplicativo são claras
  • Ele segue a regra da modularidade sobre o uso de tipagem estrita sempre que possível. Explícito é quase universalmente melhor.

Conclusão


Com exceção da familiaridade e / ou conforto, não vejo nenhum benefício em continuar a usar a cláusula ANSI-89 WHERE em vez da sintaxe ANSI-92 JOIN. Alguns podem reclamar que a sintaxe ANSI-92 é mais detalhada, mas é isso que a torna explícita. Quanto mais explícito, mais fácil é entender e manter.


14
"... Qualquer consulta envolvendo mais de uma tabela requer alguma forma de associação para vincular os resultados da tabela 'A' à tabela 'B' ... Caso contrário, você obterá um Produto Cartesiano e provavelmente não o deseja (esses cartesianos fazem produtos MALDOS).
Scott Smith

8

A maioria das pessoas tende a achar a sintaxe JOIN um pouco mais clara quanto ao que está sendo unido ao quê. Além disso, tem a vantagem de ser um padrão.

Pessoalmente, "cresci" no WHEREs, mas quanto mais uso a sintaxe JOIN, mais começo a ver como ela fica mais clara.


1
@nawfal eu entendo - fui criado com a sintaxe do estilo antigo, mas quando me acostumei com a nova, os benefícios se tornaram claros, por exemplo, mais difícil fazer uma junção cruzada por engano, mais explícito, mais fácil de ver o que é uma junção e o que é um filtro, etc ... fiquei viciado.
Básico de

8

Estes são os problemas com o uso da sintaxe where (também conhecida como junção implícita):

Em primeiro lugar, é muito fácil obter junções cruzadas acidentais porque as condições de junção não estão próximas aos nomes das tabelas. Se você tiver 6 tabelas sendo unidas, é fácil perder uma na cláusula where. Você verá isso corrigido com muita frequência usando a palavra-chave distinta. Este é um grande impacto no desempenho do banco de dados. Você não pode obter uma junção cruzada acidental usando a sintaxe de junção explícita, pois ela falhará na verificação de sintaxe.

As junções à direita e à esquerda são problemáticas (no servidor SQl não há garantia de obter os resultados corretos) na sintaxe antiga em alguns bancos de dados. Além disso, eles estão obsoletos no SQL Server, eu sei.

Se você pretende usar uma junção cruzada, isso não fica claro na sintaxe antiga. É claro usando o padrão ANSII atual.

É muito mais difícil para o mantenedor ver exatamente quais campos fazem parte da junção ou mesmo quais tabelas se juntam em que ordem usando a sintaxe implícita. Isso significa que pode levar mais tempo para revisar as consultas. Conheço muito poucas pessoas que, uma vez que dedicaram um tempo para se sentirem confortáveis ​​com a sintaxe de junção explícita, voltaram ao modo antigo.

Também observei que algumas pessoas que usam essas junções implícitas não entendem realmente como as junções funcionam e, portanto, estão obtendo resultados incorretos em suas consultas.

Honestamente, você usaria qualquer outro tipo de código que foi substituído por um método melhor há 18 anos?


6

As junções explícitas transmitem a intenção, deixando a cláusula where para fazer a filtragem. É mais limpo e é padrão, e você pode fazer coisas como o externo esquerdo ou externo direito, que é mais difícil de fazer apenas com onde.


3

Você não pode usar WHERE para combinar duas tabelas. O que você pode fazer é escrever:

SELECT * FROM A, B
WHERE ...

A vírgula aqui é equivalente a escrever:

SELECT *
FROM A
CROSS JOIN B
WHERE ...

Você escreveria isso? Não - porque não é o que você quer dizer. Você não quer uma junção cruzada, você quer um INNER JOIN. Mas quando você escreve vírgula, está dizendo CROSS JOIN e isso é confuso.


0

Na verdade, você geralmente precisa de "WHERE" e "JOIN".

"JOIN" é usado para recuperar dados de duas tabelas - com base nos valores de uma coluna comum. Se você quiser filtrar ainda mais esse resultado, use a cláusula WHERE.

Por exemplo, "LEFT JOIN" recupera TODAS as linhas da tabela da esquerda, mais as linhas correspondentes da tabela da direita. Mas isso não filtra os registros em nenhum valor específico ou em outras colunas que não fazem parte do JOIN. Portanto, se você deseja filtrar ainda mais esse resultado, especifique os filtros extras na cláusula WHERE.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.