Pourquoi certains des résultats de la requête SQL contenant certains alphabets sont manquants?
J'ai le tableau suivant

Lorsque j'exécute la requête suivante, il aurait dû afficher tout le nom de l'instructeur contenant «s», mais ce n'est pas le cas. La requête que j'ai écrite:
SQL> SELECT instructor_name
2 FROM instructor
3 WHERE instructor_name LIKE '%s%';
Le résultat est:

Quel est le problème ici? Balbir Silakar et Saurav Pangeni ne devraient-ils pas eux aussi apparaître sur le résultat?
Réponses
's'
et 'S'
sont deux choses différentes si votre colonne a un classement sensible à la casse.
Hélas, Oracle ne fournit pas de version insensible à la casse de like
(généralement appelée ilike
dans d'autres bases de données).
Vous pourriez faire:
where instructor_name like '%s%' or instructor_name like '%S%'
Ou alors:
where lower(instructor_name) like '%s%'
Ou, vous pouvez utiliser regexp_like()
; il prend un troisième argument qui peut être utilisé pour rendre la recherche insensible à la casse.
where regexp_like(instructor_name, 's', 'i')
Je ne serais pas surpris que l'expression régulière soit l'option la plus rapide des trois.
Votre base de données (par défaut je pense) est sensible à la casse, donc le mécanisme de correspondance LIKE est sensible à la casse. Ces noms contiennent un S.
Voici une question sur la façon de rendre la recherche non sensible à la casse. Effectuer une requête Like insensible à la casse dans une base de données SQL Server sensible à la casse
Pour une vérification insensible à la casse, utilisez regexp_like
where regexp_like(instructor_name , 's', 'i');
Comme d'autres l'ont mentionné, s
(chr (115)) et S
(chr (83)) sont deux choses différentes, et il n'y s
en a pas dans «Balbir Silakar» ou «Saurav Pangeni».
Depuis Oracle 12.2, vous pouvez utiliser
where instructor_name collate binary_ci like '%s%';
Vous pouvez également ignorer les accents avec
where instructor_name collate binary_ai like '%s%';