Questão de Banco de Dados — Banco de Dados Relacionais — FUNDATEC 2025
Banco de Dados›Banco de Dados Relacionais
Código
qg468569
Banca
FUNDATEC
Órgão
BRDE
Ano
2025
Nível
Superior
Cargo
Analista de Sistemas - Subárea Administração de Banco de Dados
Um desenvolvedor precisa listar todos os Funcionarios que não possuem nenhum Dependente cadastrado. Ele considera duas abordagens: uma usando NOT EXISTS e outra usando LEFT JOIN / IS NULL. Do ponto de vista de desempenho em um SGBD relacional, qual abordagem é geralmente considerada mais eficiente e por quê?
ALEFT JOIN / IS NULL, porque junções são sempre mais rápidas que subconsultas.
BNOT EXISTS, porque a subconsulta pode ser anti-join usando o índice da chave estrangeira em Dependentes.
CNOT IN, porque é a sintaxe mais simples e direta para esta necessidade.
DFULL OUTER JOIN, porque verifica a ausência de dados em ambas as tabelas.
EAmbas têm desempenho idêntico, pois o otimizador as converte para o mesmo plano.
Revelar gabarito e comentário▾
GabaritoB — NOT EXISTS, porque a subconsulta pode ser anti-join usando o índice da chave estrangeira em Dependentes.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Desempenho de anti-join: NOT EXISTS vs LEFT JOIN / IS NULL
Gabarito: letra B. A abordagem NOT EXISTS é geralmente mais eficiente porque o otimizador pode transformá-la em um anti-join, explorando índices da chave estrangeira em Dependentes para verificar rapidamente a ausência de correspondências, enquanto o LEFT JOIN / IS NULL pode exigir processamento extra de todas as combinações antes de filtrar os nulos.
A banca testa o conhecimento sobre otimização de consultas SQL para a operação de anti-join (buscar registros sem correspondentes). O desempenho depende de como o SGBD executa cada plano.
Alternativa A — ❌ Incorreta
Afirma que junções são sempre mais rápidas que subconsultas, o que é falso. Neste caso, a subconsulta NOT EXISTS pode ser mais rápida por se beneficiar de um anti-join com índice, enquanto o LEFT JOIN pode gerar uma junção externa que requer mais processamento (tabelas grandes).
Alternativa B — ✅ Correta ⟵ GABARITO
O NOT EXISTS permite que o otimizador do SGBD implemente um anti-join, que pode usar o índice da chave estrangeira em Dependentes (FK_Funcionario) para verificar se existe ao menos uma linha correspondente. Se não encontrar, o registro é retornado. Isso é geralmente mais eficiente do que gerar todas as combinações com LEFT JOIN e depois filtrar os nulos.
Alternativa C — ❌ Incorreta
NOT IN é semanticamente semelhante, mas pode ter problemas com NULLs e, em alguns SGBDs, ter desempenho inferior a NOT EXISTS, especialmente se a subconsulta retornar muitos valores ou contiver NULLs. A sintaxe mais simples não garante eficiência.
Alternativa D — ❌ Incorreta
FULL OUTER JOIN retorna todos os registros de ambas as tabelas, combinados onde há correspondência, e inclui nulos para os lados sem correspondência. Para listar funcionários sem dependentes, ele traria também dependentes sem funcionários (se houver), o que é desnecessário e geralmente mais custoso.
Alternativa E — ❌ Incorreta
O otimizador pode converter algumas consultas equivalentes para o mesmo plano, mas isso não é garantido. Em muitos SGBDs, NOT EXISTS e LEFT JOIN/IS NULL podem gerar planos diferentes, sendo o primeiro mais eficiente em cenários típicos com índices.
PEGA ESSA DICA!
Na prova, lembre-se: para anti-join (buscar o que não existe), prefira NOT EXISTS quando houver índice na coluna de junção. LEFT JOIN/IS NULL funciona, mas pode ser mais lento. NOT IN é arriscado com NULLs.