Questão de Banco de Dados — SQL — Avança SP 2025

ORM no Django: mapeamento objeto-relacional

Gabarito: letra A. A principal vantagem do ORM (Object-Relational Mapping) do Django é o mapeamento automático entre objetos Python e tabelas do banco de dados, mantendo a consistência do modelo de dados — é exatamente isso que a alternativa A descreve. O ORM traduz as classes do modelo em tabelas e as instâncias em linhas, permitindo que o desenvolvedor trabalhe com objetos em vez de escrever SQL manualmente.

O ORM (Object-Relational Mapping, ou Mapeamento Objeto-Relacional) é uma técnica que cria uma ponte entre o paradigma de programação orientado a objetos e o modelo relacional de banco de dados. No Django, cada classe que herda de models.Model representa uma tabela, e cada atributo da classe representa uma coluna. Quando você cria, consulta ou atualiza um objeto Python, o ORM traduz essas operações em comandos SQL automaticamente.

A grande vantagem dessa abordagem é a consistência do modelo de dados: como o esquema do banco é derivado diretamente das classes Python, as alterações no código refletem no banco de forma coordenada (através das migrations), reduzindo erros de digitação em SQL, problemas de conversão de tipos e a necessidade de sincronizar manualmente o código com o esquema do banco.

Na prática, em vez de escrever SELECT * FROM cliente WHERE nome = 'João', você escreve Cliente.objects.filter(nome='João'). O ORM cuida da geração do SQL, da conexão com o banco e da conversão dos resultados em objetos Python. Isso torna o código mais limpo, mais seguro (proteção contra SQL injection) e mais portável entre diferentes SGBDs (SQLite, PostgreSQL, MySQL, Oracle), pois o ORM gera o dialeto SQL adequado para cada um.

É importante distinguir o ORM de outras abordagens: enquanto o SQL puro dá controle total sobre a consulta, o ORM prioriza a produtividade e a abstração. A performance de consultas complexas geralmente é melhor com SQL puro otimizado, não com ORM — o ORM pode gerar consultas ineficientes se não for bem utilizado. Stored procedures não são suportadas nativamente pelo ORM do Django (é preciso usar SQL cru para isso). E o ORM, por definição, abstrai o SQL — não dá mais controle sobre ele, mas sim menos.

A pegadinha desta questão está em inverter os papéis: o ORM não é sobre performance, controle ou suporte a recursos específicos do banco — é sobre abstração e produtividade. Guarde essa fronteira: ORM = mapeamento automático e consistência; SQL puro = controle fino e performance potencialmente melhor.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta é a definição central do ORM: o mapeamento automático entre objetos Python e tabelas do banco. No Django, as classes do modelo (models.Model) são convertidas em tabelas, e as instâncias em linhas, mantendo a consistência entre o código e o esquema do banco. É a principal vantagem porque elimina o trabalho manual de escrever SQL para cada operação e garante que o modelo de dados da aplicação esteja sempre alinhado com o banco.

Alternativa B — ❌ Incorreta

Afirma que o ORM oferece melhor performance em consultas complexas — é o oposto. O ORM adiciona uma camada de abstração que pode gerar consultas SQL ineficientes (problema conhecido como N+1 queries). Para consultas complexas, o SQL puro ou otimizações específicas (como select_related e prefetch_related) são mais eficazes. A performance não é a vantagem do ORM, mas sim a produtividade.

Alternativa C — ❌ Incorreta

O ORM do Django não tem suporte nativo a stored procedures. Para usar stored procedures, é necessário recorrer a SQL cru (connection.cursor()). O ORM é focado em operações CRUD e consultas comuns, não em recursos avançados específicos de cada SGBD. Essa alternativa confunde o ORM com uma ferramenta de acesso completo ao banco.

Alternativa D — ❌ Incorreta

O ORM dá menos controle sobre as consultas SQL geradas, não mais. O desenvolvedor escreve em Python e o ORM decide como traduzir para SQL. Para ter controle fino sobre a consulta, é preciso usar SQL cru ou ferramentas de otimização. A alternativa inverte o sentido: quem quer controle usa SQL puro, quem quer abstração usa ORM.

Alternativa E — ❌ Incorreta

O ORM não facilita escrever consultas complexas em SQL — ele elimina a necessidade de escrever SQL. A proposta do ORM é trabalhar com objetos Python, não com SQL. Para consultas complexas, o ORM pode até atrapalhar, exigindo truques como Q objects ou RawSQL. A facilidade do ORM está em operações comuns, não em SQL complexo.

Gabarito: letra A