João trabalha na migração para o MySQL de um sistema baseado originalmente no SQL Server. Nesse contexto, nos comandos SQL que eventualmente utilizem o operador like, João:
- A)é obrigado a substituir o operador like pelo operador regexp;
Errada, porque o MySQL possui o operador LIKE e não obriga a substituição por REGEXP.
- B)pode manter o comando como está, pois o MySQL interpreta o operador corretamente;
Certa, porque o MySQL interpreta o operador LIKE normalmente, preservando a lógica usada no SQL Server.
- C)pode manter o comando, mas deve substituir todas as ocorrências do caractere curinga “%” por “*”;
Errada, porque % é o curinga correto do LIKE para qualquer sequência de caracteres, e * não é substituto nessa sintaxe.
- D)pode manter o comando, mas deve substituir todas as ocorrências do caractere curinga “*” por “%”;
Errada, porque * não é coringa do LIKE em SQL; o símbolo % é o correto para esse papel.
- E)pode manter o comando, mas deve substituir todas as ocorrências do caractere curinga “?” por “_”.
Errada, porque ? não é o curinga do LIKE; no SQL, o caractere para um único caractere é _.
Gabarito: B
Na migração de SQL Server para MySQL, a boa notícia é que o operador LIKE continua existindo e funciona de forma muito parecida nos dois bancos. Ou seja, você não precisa trocar o comando por REGEXP só por causa da mudança de SGBD. O padrão de comparação textual com curingas é mantido, então a lógica da consulta segue intacta. No LIKE, os curingas clássicos são % e _, e não * e ?. O símbolo % representa qualquer sequência de caracteres, inclusive vazia, enquanto _ representa exatamente um caractere. Isso é o que costuma cair em prova quando a banca quer ver se você confunde sintaxe de SQL com padrões de outros contextos, como glob ou expressões regulares. Por isso, o gabarito é a letra B. O MySQL interpreta o LIKE corretamente, sem exigir substituições de curinga. Se o comando já estava escrito de forma adequada no SQL Server, em regra ele pode ser mantido no MySQL, respeitando apenas eventuais diferenças específicas de collation, sensibilidade a maiúsculas/minúsculas ou configurações do servidor. Em resumo: LIKE permanece LIKE, % continua sendo % e _ continua sendo _. A FGV gosta justamente dessa pegadinha de misturar símbolos de outras linguagens ou ferramentas para ver se você troca o que não deve.