Découvrir PostgreSQL

Comprendre la sensibilité à la casse

Testez gratuitement nos 1254 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Voyez comment PostgreSQL gère la sensibilité à la casse. Vous allez vous intéresser à la syntaxe de la requête et à la recherche de chaînes de caractères.
05:06

Transcription

Avant de commencer à voir le langage SQL propre à Postgres, une note sur la sensibilité à la casse, c'est-à-dire majuscule, minuscule. Vous voyez que pour l'instant, j'ai fait des requêtes comme ça, j'ai mis mes " SELECT " en majuscules, mes " FROM " en majuscules, pourquoi ? Parce que c'est une convention personnelle et c'est comme ça que j'aime bien le faire. Mais ça n'a absolument aucune importance. Qu'est-ce que je viens de faire d'ailleurs ici dans pgAdmin ? C'est " Ctrl+Maj+U ". Souvenez-vous du U pour upper ou uppercase, donc majuscule. Si vous faites " Ctrl+U ", vous mettez quelque chose en majuscules. Et si vous faites " Ctrl+Maj+U ", vous le mettez en minuscules. Est-ce que ça donne quelque chose, bien sûr. Qu'en est-il du nom des objets par contre ? Si je regarde dans mon explorateur, je vois que le schéma " contact " est marqué en minuscules. Ça n'a pas beaucoup d'importance. Parce que je peux le mettre en majuscules, ça aussi d'ailleurs. Et j'aurai toujours le résultat. Donc, il n'y a pas vraiment d'importance dans votre syntaxe, dans le code SQL lui-même, en ce qui concerne le choix majuscules, minuscules. Ça peut avoir un impact seulement si vous protégéz vos identifiants, de cette façon. C'est-à-dire que le guillemet double permet, dans le langage SQL, d'exprimer un identifiant en le protégeant s'il contient des caractères spéciaux, ce que vous n'avez normalement pas besoin de faire. Mais si donc je fais cela, on ne connaît plus, vous voyez, " contact.contact ". Vous voyez la différence. J'ai tout écrit en majuscules, mais ici on me dit, la relation " contact " en minuscules, " .CONTACT " en majuscules, n'existe pas. Dès que vous protégez votre identifiant, il va être inscrit tel quel. Mais si vous ne le protégéz pas, il sera converti en minuscules par Postgres, et on trouvera le schéma. Ce qu'il faut faire, c'est autant que possible, de toute façon, respecter la casse. Mettez tout en minuscules, en ce qui concerne les identifiants. Mettez en minuscules ou en majuscules, comme vous préférez, les mots clés du langage SQL, et vous n'aurez aucun problème. Moi, mes conventions, la façon dont j'aime travailler, c'est plutôt comme ceci. En ce qui concerne la recherche dans les chaînes de caractères, c'est plus compliqué. Parce que si je fais par exemple le nom, donc que je peux écrire comme ceci, on a bien compris, comme ceci, comme ceci, je vais rester ainsi, parce que c'est vraiment tel qu'il est inscrit dans la base de données. Ensuite, je cherche une chaîne de caractères, que je dois exprimer en tant que littérale avec des apostrophes, comme dans tous les dialectes SQL. Ensuite, je vais inscrire " Lemoine ", comme ceci parce que je vois qu'il y a un L majuscule, et le reste est en minuscules. Et je vais les trouver. Je suis dans ma recherche de chaînes de caractères stockées dans des varchar, ou dans des colonnes de type texte, totalement sensibles à la casse. Si je fais ceci, je vais être perdu. Est-ce que j'ai un moyen de m'en sortir ? Oui et non. Vous avez plusieurs solutions. Vous pouvez utiliser le " LIKE ". Le " LIKE ", vous connaissez sans doute, c'est une recherche de pattern. Donc, je vais faire un " LIKE " avec des % éventuellement, pour trouver tout ce qu'il y a au début, à la fin. Mais je peux faire un " LIKE " comme ceci, ça je trouve, ça est-ce que je trouve ? Toujours pas et vous allez me dire pourquoi il me parle de " LIKE " ? Parce qu'il y a une version, une variante qui s'appelle " ILIKE ". I pour insentitive, insensible à la casse, qui cette fois-ci va trouver les correspondances. Alors méfiez-vous du " ILIKE ". C'est-à-dire que là il est très pratique, ça va bien. Mais vous pourriez avoir des problématiques de performance, sur des volumes plus importants. Parce que ça change le plan d'exécution, et que la recherche va être beaucoup plus coûteuse, notamment si vous avez un index, ça ne va pas forcément utiliser l'index sur le nom. Ce que vous pouvez faire aussi, c'est de créer justement un index sur le nom, et de créer cet index à partir d'une fonction. Donc ça je vous en parlerai juste un peu plus tard, parce qu'il faut qu'on voit les index. Ce que vous pouvez faire également, et qui n'est pas non plus extraordinaire en termes de performance, c'est d'utiliser une fonction spécifique qui s'appelle " LOWER ", et qui va donc prendre les " noms ", les mettre tous en minuscules, et ensuite tester avec une valeur totalement en minuscules, comme ceci et ça va fonctionner également. Mais, ce n'est pas forcément très très bon en termes de performance non plus, si vous avez des tables volumineuses.

Découvrir PostgreSQL

Comprenez le fonctionnement de PostgreSQL ainsi que son architecture. Effectuez les tâches courantes de sécurité, de création de bases de données et d'objets, etc.

2h46 (30 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
PostgreSQL PostgreSQL 9
Spécial abonnés
Votre/vos formateur(s) :
Date de parution :31 mars 2016
Durée :2h46 (30 vidéos)

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !