© Éditions Eyrolles
21
chapitre n° 1
Définition des données
MySQL n’est pas sensible à la casse tous systèmes confondus. En fait, tous ces noms sont
stockés en minuscules dans le dictionnaire de données.
La variable lower_case_table_names permet de forcer la sensibilité à la casse pour
les noms des tables et des bases de données (si elle vaut 0, la sensibilité à la casse est active et
les noms sont stockés en minuscules ; 1, pas de sensibilité à la casse et les noms sont
stockés en minuscules ; 2, pas de sensibilité à la casse et les noms sont stockés en respectant la
casse).
Je vous invite à positionner cette variable à 0 de manière à homogénéiser le codage et à
contrôler un peu plus l’écriture de vos instructions SQL. De plus, c’est l’option par défaut sur
Linux. Dans le fichier my.ini , sous la section serveur identifiée par [ mysqld ], ajouter la
ligne et le commentaire suivants :
# Rend sensible à la CASSE les noms de tables et de database
lower_case_table_names=0
Refusez ce type de programmation (rendue impossible d’ailleurs si la variable lower_case_
table_names est positionnée à 0).
mysql> SELECT * FROM Avion WHERE AVION .capacite > 150;
Par ailleurs, la casse devrait toujours avoir (quel que soit le SGBD concerné) une incidence
majeure dans les expressions de comparaison entre colonnes et valeurs, que ce soit dans une
instruction SQL ou un test dans un programme.
Ainsi l’expression « nomComp='Air France' » a la même signification que l’expression
« nomComp='AIR France' » avec MySQL ! Horreur, oui.
Donc, si vous désirez vérifier la casse au sein même des données, il faudra utiliser la fonction
BINARY() qui convertit en bits une expression. En effet, « BINARY('AIR France') » est différent de « BINARY('Air France') » et « BINARY(nomComp)=BINARY('Air France') »
renverra vrai en respectant la casse.
Commentaires
Dans toute instruction SQL (déclaration, manipulation, interrogation et contrôle des données),
il est possible d’inclure des retours chariot, des tabulations, espaces et commentaires (sur une
ligne précédée de deux tirets « – - », en fin de ligne à l’aide du dièse « # », au sein d’une
ligne ou sur plusieurs lignes entre « /* » et « */ »). Les scripts suivants décrivent la déclaration d’une même table en utilisant différentes conventions :
21
chapitre n° 1
Définition des données
MySQL n’est pas sensible à la casse tous systèmes confondus. En fait, tous ces noms sont
stockés en minuscules dans le dictionnaire de données.
La variable lower_case_table_names permet de forcer la sensibilité à la casse pour
les noms des tables et des bases de données (si elle vaut 0, la sensibilité à la casse est active et
les noms sont stockés en minuscules ; 1, pas de sensibilité à la casse et les noms sont
stockés en minuscules ; 2, pas de sensibilité à la casse et les noms sont stockés en respectant la
casse).
Je vous invite à positionner cette variable à 0 de manière à homogénéiser le codage et à
contrôler un peu plus l’écriture de vos instructions SQL. De plus, c’est l’option par défaut sur
Linux. Dans le fichier my.ini , sous la section serveur identifiée par [ mysqld ], ajouter la
ligne et le commentaire suivants :
# Rend sensible à la CASSE les noms de tables et de database
lower_case_table_names=0
Refusez ce type de programmation (rendue impossible d’ailleurs si la variable lower_case_
table_names est positionnée à 0).
mysql> SELECT * FROM Avion WHERE AVION .capacite > 150;
Par ailleurs, la casse devrait toujours avoir (quel que soit le SGBD concerné) une incidence
majeure dans les expressions de comparaison entre colonnes et valeurs, que ce soit dans une
instruction SQL ou un test dans un programme.
Ainsi l’expression « nomComp='Air France' » a la même signification que l’expression
« nomComp='AIR France' » avec MySQL ! Horreur, oui.
Donc, si vous désirez vérifier la casse au sein même des données, il faudra utiliser la fonction
BINARY() qui convertit en bits une expression. En effet, « BINARY('AIR France') » est différent de « BINARY('Air France') » et « BINARY(nomComp)=BINARY('Air France') »
renverra vrai en respectant la casse.
Commentaires
Dans toute instruction SQL (déclaration, manipulation, interrogation et contrôle des données),
il est possible d’inclure des retours chariot, des tabulations, espaces et commentaires (sur une
ligne précédée de deux tirets « – - », en fin de ligne à l’aide du dièse « # », au sein d’une
ligne ou sur plusieurs lignes entre « /* » et « */ »). Les scripts suivants décrivent la déclaration d’une même table en utilisant différentes conventions :