SUBQUERY vs INNER JOIN

SUBQUERY
VS
INNER JOIN
https://medium.com/@gugoiscardoso

1
SUBQUERY vs INNER JOIN

Subquery x Inner Join

Quero compartilhar uma maneira fácil e rápida de escolher entre subquery e inner join
sem a necessidade de conhecimento sobre regras de performance.
Não sei vocês, mas para mim, a performance é um dos fatores mais importantes para
decidir entre uma ou outra instrução sql. Porém, existem outras características que podem ser
avaliadas, falaremos mais sobre elas a baixo.
Antes de mais nada, segue definição e exemplos das duas instruções sql:
Subquery
Subconsulta (mais conhecida como subquery) é uma instrução SELECT que está
condicionada dentro de outra instrução SQL.
Exemplo:
Temos a tabela funcionário com 3 campos: Id, Nome e Salário. A partir delas, criei uma
subquery que retorna todos os funcionários com o salário maior que a média salarial.
-- retorna todos os funcionários com salário maior que a média
salarial.
SELECT * FROM funcionario WHERE salario >

(SELECT AVG(salario) FROM funcionário)

Como podemos ver acima, subquery é basicamente uma instrução sql dentro da outra.
Apesar de ser um exemplo simples, representa com clareza o que é uma subquery.
Inner Join
Quando comecei a estudar banco de dados, por diversas vezes fiz o inner join, com a
intenção de “juntar” os dados. Essa definição ficou na minha cabeça e sempre me pareceu
vaga.
Um belo dia, conheci um professor que resolveu iluminar meu caminho nas artes do join.
Segue abaixo, a imagem milagrosa:

2
SUBQUERY vs INNER JOIN

FIGURA 1: SQL Joins

O Join, em síntese, é a junção de duas ou mais coleções de dados. Nessa operação de

mescla, é possível atribuir filtros, ordenações e etc.
A figura a cima, exemplifica a query e seu respectivo comportamento em relação ao
conjunto de dados. Os círculos representam uma determinada entidade e as intersecções entre
eles exemplificam suas relações.
Exemplo:

Figura 2 : Relacionamentos

Nesse ponto, criamos a tabela Departamento. Nela, temos 3 colunas: Id, Nome e
Descrição. Em seguida criamos a coluna IdDepartamento na tabela Funcionário
(com FK) para realizarmos o join:
-- retorna uma lista de funcionários com seus respectivos
departamentos
SELEC * FROM funcionario F
INNER JOIN departamento D ON F.iddepatamento = D.id

Dessa maneira, é possível relacionar as duas entidades e retornar o conjunto de sua

união, através do match de valores do id da entidade departamento com o idDepartamento
da entidade funcionário.
Após esse pequeno resumo sobre os dois, vamos à solução prática para escolher entre
ambos e garantir que sua escolha seja a certa.
No meu ambiente de trabalho, prezamos muito a entrega de nossos projetos. Não são
100% dos casos que dão certo, mas a intenção é sempre boa. Pensando nisso, quando me
deparei com a situação em que eu tinha que saber qual dos dois era mais performático, qual era
o “melhor”, simplesmente analisei o tempo que tinha pra entregar e cheguei à seguinte
conclusão:
Existem duas possibilidades que considero viáveis. A primeira delas é utilizar um
software que compare suas querys. O próprio Microsoft Server Sql Management Studio tem
em suas features essa possibilidade. Veja o exemplo abaixo:
Primeiro, criamos a query em suas duas versões, uma com o inner join e a outra
com subquery. Nossa query retornará o nome dos funcionários do departamento de TI.
-- retorna o nome dos funcionários do departamento de TI
//Subquery
SELECT F.nome FROM funcionarios F WHERE D.iddeparmento
IN (SELECT D.id FROM departamento D WHERE F.nome = ’TI’)
//Inner Join
SELECT F.nome FROM departamento D INNER JOIN funcionario F

3
SUBQUERY vs INNER JOIN

ON D.id = F.iddepartamento WHERE D.nome = ‘TI’

Após executarmos as querys com o atalho ctrl + L (Exibir plano de execução estimado),
é possível visualizar o plano de execução de cada uma das querys.

Inner Join Subquery

Figura 4: Subquery
Figura 3: Inner Join

Dessa maneira, conseguimos comparar as duas querys e tomar uma decisão tecnológica
considerada adequada.

Até esse ponto, a análise é simples pois levamos em consideração apenas a performance.
Mas consideraremos agora o tão importante prazo, que na minha opinião será o fator decisivo
na sua escolha.

Pensemos em um cenário onde o prazo influencia: Você trabalha em um projeto há

alguns meses e está com o prazo apertado. Em um determinado momento se depara com esse
problema, a necessidade de escolher entre subquery e inner join.

É viável investir tempo na escrita de querys de maneiras diferentes para avaliar performance ? Será que
não é um tempo que pode fazer falta no futuro ?

Sabemos a importância do tempo nos nossos projetos. Bugs acontecem, mudanças no

escopo do projeto também (não deveria) e o tempo para o bar do final de semana é
importante !

Então, defendo que o dia a dia reflete diretamente nas nossas decisões e que o tempo, no
final, será o fator mais relevante. Sem tempo para analisar, eu faço da maneira que é mais
confortável pra mim. Nesse contexto, complexidade da sintaxe e o tempo que leva pra escrever
uma query são as características que considero decisivas.

Acho que o mais importante, em contextos que você precisa comparar e tomar decisões
em relação à tecnologias, é utilizar do bom senso pra conseguir analisar bem a situação e
chegar a uma solução bacana.