Questão de Banco de Dados — SQL — FGV 2025

SQL: busca por termo no campo descrição

Gabarito: letra B. Para consultar apenas os processos que possuem o termo “trabalhista” no campo descricao, a condição correta é descricao ilike 'trabalhista', pois o operador ILIKE realiza uma busca por padrão sem diferenciar maiúsculas de minúsculas, e, sem os curingas %, exige que o valor do campo seja exatamente “trabalhista” (ou qualquer variação de caixa, como “Trabalhista” ou “TRABALHISTA”). As demais alternativas ou comparam por igualdade exata (case-sensitive), ou usam sintaxe incorreta, ou não filtram adequadamente.

A questão cobra o conhecimento dos operadores de comparação e busca de padrões em SQL, especificamente a diferença entre = (igualdade exata), LIKE/ILIKE (busca por padrão com curingas) e funções como POSITION. O enunciado pede para consultar processos que “possuem o termo ‘trabalhista’ no campo descrição”. A interpretação mais direta é que o campo descricao deve conter exatamente a palavra “trabalhista” (não parte dela, como em “processo trabalhista” ou “ação trabalhista”). Se a intenção fosse buscar qualquer descrição que contenha a palavra em qualquer posição, usaríamos LIKE '%trabalhista%'. No entanto, a alternativa B usa ILIKE 'trabalhista' sem curingas, o que corresponde a uma igualdade exata, mas insensível a maiúsculas/minúsculas. Isso atende ao pedido literal de “possuem o termo ‘trabalhista’”, considerando que o termo é o valor completo do campo.

O operador LIKE é usado para busca por padrão, onde % representa qualquer sequência de caracteres (inclusive vazia) e _ representa um único caractere. O ILIKE é a versão case-insensitive do LIKE, disponível em bancos como PostgreSQL. A alternativa B, descricao ilike 'trabalhista', sem curingas, é equivalente a descricao = 'trabalhista' mas ignorando maiúsculas/minúsculas. Isso significa que retornará registros onde o campo descricao é exatamente “trabalhista”, “Trabalhista”, “TRABALHISTA”, etc. Essa é a condição que atende ao pedido do enunciado, que busca processos que “possuem o termo ‘trabalhista’ no campo descrição”.

A pegadinha da questão está em interpretar “possuem o termo” como “contêm a palavra em qualquer posição”, o que levaria a usar LIKE '%trabalhista%'. No entanto, a alternativa B não usa curingas, indicando que a banca considera que o termo é o valor exato do campo. Além disso, a alternativa A (descricao = 'trabalhista') é case-sensitive, o que não atenderia a variações como “Trabalhista”. A alternativa E (POSITION('trabalhista' IN descricao)) retorna a posição do termo, mas não é uma condição booleana válida para o WHERE sem uma comparação adicional. As alternativas C e D usam sintaxe incorreta: '_trabalhista_' != descricao compara com curingas literais, e '%trabalhista%' IN descricao usa IN de forma inadequada.

Guarde a distinção entre = (igualdade exata, case-sensitive), LIKE (busca por padrão com curingas, case-sensitive) e ILIKE (busca por padrão case-insensitive). É exatamente nessa fronteira que as alternativas se dividem: a correta usa ILIKE sem curingas, enquanto as incorretas ou usam = (case-sensitive), ou usam curingas de forma errada, ou têm sintaxe inválida.

Alternativa A — ❌ Incorreta

descricao = 'trabalhista' compara por igualdade exata, que é case-sensitive em SQL padrão. Isso significa que só retornaria registros onde o campo é exatamente “trabalhista” em minúsculas, não atendendo a variações como “Trabalhista” ou “TRABALHISTA”. O enunciado pede “possuem o termo ‘trabalhista’”, o que sugere que a busca deve ser insensível a maiúsculas/minúsculas, como faz o ILIKE. Além disso, sem curingas, = exige que o valor seja exatamente o termo, o que é o mesmo comportamento do ILIKE sem curingas, mas sem a flexibilidade de caixa.

Alternativa B — ✅ Correta ⟵ GABARITO

descricao ilike 'trabalhista' usa o operador ILIKE, que é a versão case-insensitive do LIKE. Sem os curingas % ou _, ele exige que o campo descricao seja exatamente “trabalhista”, mas aceita qualquer variação de maiúsculas/minúsculas (ex.: “Trabalhista”, “TRABALHISTA”). Isso atende ao pedido do enunciado de consultar processos que “possuem o termo ‘trabalhista’ no campo descrição”, considerando que o termo é o valor completo do campo. É a condição correta.

Alternativa C — ❌ Incorreta

'_trabalhista_' != descricao usa os curingas _ (que representam um único caractere) dentro de uma comparação de desigualdade. Isso não é uma busca por padrão válida: o _ é um curinga do LIKE, não do =. Além disso, a condição != (diferente) retornaria todos os registros que não são exatamente “trabalhista” (com os underscores literais), o que não filtra os processos que possuem o termo. A sintaxe correta para busca por padrão seria descricao LIKE '_trabalhista_', mas mesmo assim não atenderia ao pedido, pois exigiria um caractere antes e depois do termo.

Alternativa D — ❌ Incorreta

'%trabalhista%' IN descricao usa o operador IN de forma incorreta. O IN é usado para comparar um valor com uma lista de valores, como descricao IN ('a', 'b'). Aqui, a sintaxe está invertida: o padrão '%trabalhista%' está sendo comparado com o campo descricao, o que não é válido. A forma correta de buscar um padrão seria descricao LIKE '%trabalhista%', que retornaria registros onde o campo contém a palavra “trabalhista” em qualquer posição. No entanto, essa não é a alternativa correta, pois o enunciado pede que o termo seja o valor exato do campo, não parte dele.

Alternativa E — ❌ Incorreta

POSITION('trabalhista' IN descricao) retorna a posição (número inteiro) onde o termo “trabalhista” aparece no campo descricao. Se o termo não for encontrado, retorna 0. No entanto, essa função não é uma condição booleana válida para o WHERE sem uma comparação adicional, como POSITION('trabalhista' IN descricao) > 0. Mesmo assim, essa condição retornaria registros onde o termo aparece em qualquer posição, o que não atende ao pedido de que o termo seja o valor exato do campo. A alternativa B é mais direta e correta.

Gabarito: letra B