Questão de Banco de Dados — Banco de Dados Relacionais — FGV 2025
Banco de Dados›Banco de Dados Relacionais
Código
fg107869
Banca
FGV
Órgão
CPRM
Ano
2025
Nível
Superior
Cargo
Analista em Geociências - Geoprocessamento
Em uma aplicação Django com grandes volumes de dados, o tempo de carregamento de páginas que acessam relações ForeignKey cresceu consideravelmente. O desenvolvedor deseja otimizar isso sem alterar a lógica da view.O comando mais apropriado neste caso é
Aall().values()
B.aggregate()
C.filter(prefetch_related=True)
D.select_related()
E.select_aggregate()
Revelar gabarito e comentário▾
GabaritoD — .select_related()
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”.
Django: Otimização de consultas com ForeignKey
Gabarito: letra D (.select_related()). O método select_related() realiza um JOIN SQL entre a tabela principal e a tabela relacionada via ForeignKey, trazendo os dados em uma única consulta. Isso resolve o problema de consultas N+1, reduzindo drasticamente o número de acessos ao banco de dados e melhorando o desempenho sem alterar a lógica da view.
A questão aborda um problema clássico de desempenho em Django: ao acessar um campo ForeignKey em um loop, cada acesso gera uma consulta adicional ao banco. O Django oferece dois métodos principais para otimização: select_related() e prefetch_related(). A escolha correta depende do tipo de relacionamento.
Método
Função
Tipo de Relação Otimizada
Efeito na Consulta
Uso Correto
select_related()
Realiza JOIN SQL
ForeignKey (muitos-para-um)
Reduz consultas N+1 para 1
Relações diretas
prefetch_related()
Consulta separada + cache
Muitos-para-muitos, reversa
Reduz consultas N+1 para 2
Relações indiretas
all().values()
Retorna dicionários
Nenhuma
Não otimiza
Apenas formatação
.aggregate()
Cálculos agregados
Nenhuma
Não otimiza
SUM, COUNT, AVG
.select_aggregate()
Inexistente
N/A
N/A
Não é método Django
Otimização de consultas Django
1Relação ForeignKey (muitos-para-um)
select_related() — JOIN SQL
prefetch_related() — consulta extra
2Relação M2M ou reversa
select_related() — não funciona
prefetch_related() — consulta separada
3Métodos incorretos
all().values() — sem otimização
aggregate() — cálculos agregados
select_aggregate() — não existe
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
all().values() retorna um QuerySet de dicionários, mas não otimiza o carregamento das relações. Ainda haveria múltiplas consultas para acessar os objetos relacionados.
Alternativa B — ❌ Incorreta
.aggregate() é usado para cálculos agregados como SUM, COUNT, etc. Não tem relação com otimização de carregamento de relações ForeignKey.
Alternativa C — ❌ Incorreta
.filter(prefetch_related=True) não é uma sintaxe válida. O correto seria usar prefetch_related() separadamente. Além disso, prefetch_related() é mais adequado para relações muitos-para-muitos e relações reversas de ForeignKey, não para ForeignKeys diretas (muitos-para-um). Para ForeignKeys, o ideal é select_related().
Alternativa D — ✅ Correta ⟵ GABARITO
select_related() realiza um JOIN SQL e recupera os objetos da relação ForeignKey na mesma consulta. É a solução correta para o problema de grandes volumes de dados com acessos a ForeignKey, pois elimina as consultas extras.
Alternativa E — ❌ Incorreta
.select_aggregate() não é um método do Django. O método agregado é .aggregate().
NÃO CAIA NESSA!
A banca pode confundir o candidato entre select_related() e prefetch_related(). Lembre-se: select_related() serve para relações ForeignKey (direta, muitos-para-um) e faz JOIN. prefetch_related() serve para relações muitos-para-muitos e relações reversas (ex.: um autor com vários livros). Sempre verifique o tipo de relação.