Questão de Banco de Dados — Consultas e Comandos em SQL — VUNESP 2025

SQL: operador LIKE e junção de tabelas

Gabarito: letra B. O comando correto usa LIKE 'Joao%' para capturar nomes que começam com "Joao" (o curinga % no final), e faz a junção entre as tabelas usuario e post pela chave estrangeira usuario_id — exatamente o que a alternativa B apresenta. As demais alternativas erram ou na posição do curinga, ou na ausência da junção, ou na coluna filtrada.

O operador LIKE é o recurso do SQL para busca por padrão em strings, usando dois curingas: % (qualquer sequência de caracteres, inclusive vazia) e _ (um único caractere). A posição do % define o que se está procurando: 'Joao%' casa com strings que começam com "Joao" (ex.: "Joao Silva", "Joao Pedro"); '%Joao' casa com strings que terminam com "Joao" (ex.: "Maria Joao"); e '%Joao%' casa com strings que contêm "Joao" em qualquer posição (ex.: "Antonio Joao Carlos").

No modelo relacional, para retornar dados de duas tabelas relacionadas (aqui, usuario e post), é obrigatório usar uma junção — INNER JOIN — especificando a condição de igualdade entre a chave primária de uma e a chave estrangeira da outra. No caso, usuario.id = post.usuario_id conecta cada post ao seu autor. Sem essa junção, não há como cruzar os dados das duas tabelas, e a consulta fica incompleta ou incorreta.

A pegadinha central desta questão é a posição do curinga % em relação ao termo "Joao". O enunciado pede nomes que se iniciam com "Joao" — ou seja, o padrão deve começar com "Joao" e permitir qualquer continuação. Isso exige o % depois de "Joao" ('Joao%'), nunca antes. Colocar o % antes ('%Joao') inverteria o sentido, retornando nomes que terminam com "Joao".

Outra armadilha é a ausência da junção em algumas alternativas: sem o INNER JOIN, não é possível relacionar os posts aos seus autores, tornando a consulta inválida para o que se pede. E há ainda a alternativa que filtra a coluna errada (WHERE usuário LIKE), o que não faz sentido, pois a condição deve recair sobre a coluna nome da tabela usuario.

Guarde a regra de ouro: o curinga % fica do lado onde a string pode continuar. Para nomes que começam com um termo, o % vai no final; para nomes que terminam, o % vai no início; para nomes que contêm, o % vai dos dois lados. E, em consultas com múltiplas tabelas, a junção é sempre necessária.

Alternativa A — ❌ Incorreta

O erro está no padrão '%Joao': o curinga % antes de "Joao" faz a busca retornar nomes que terminam com "Joao", não os que se iniciam. O enunciado pede nomes que começam com "Joao", o que exige o % depois do termo ('Joao%'). A junção está correta, mas o filtro está invertido.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta alternativa reúne todos os elementos corretos: faz a junção INNER JOIN entre usuario e post pela condição usuario.id = post.usuario_id, seleciona a coluna post.titulo e aplica o filtro WHERE nome LIKE 'Joao%', que retorna exatamente os nomes que se iniciam com "Joao". O % no final permite qualquer continuação, como "Joao Silva" ou "Joao Pedro".

Alternativa C — ❌ Incorreta

Faltou a junção entre as tabelas usuario e post — sem o INNER JOIN, não é possível relacionar os posts aos seus autores, e a consulta não retornaria os títulos corretamente. Além disso, o filtro está aplicado sobre a tabela usuário (WHERE usuário LIKE), quando deveria ser sobre a coluna nome da tabela usuario.

Alternativa D — ❌ Incorreta

O padrão '%Joao%' retorna nomes que contêm "Joao" em qualquer posição — no início, no meio ou no fim. O enunciado pede especificamente nomes que se iniciam com "Joao", o que exige o % apenas no final ('Joao%'). Além disso, a alternativa não faz a junção com a tabela post, tornando a consulta incapaz de retornar os títulos.

Alternativa E — ❌ Incorreta

Embora o filtro LIKE 'Joao%' esteja correto, a alternativa não faz a junção entre as tabelas usuario e post. Sem o INNER JOIN, a consulta não tem como relacionar cada post ao seu autor, e portanto não retornaria os títulos dos posts dos usuários filtrados.

Gabarito: letra B