La syntaxe SQL est-elle sensible à la casse?
https://stackoverflow.com/questions/153944
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Est-ce que SQL est sensible à la casse. J'ai utilisé MySQL et SQL Server, qui semblent tous deux être sensibles à la casse. Est-ce toujours le cas? La norme définit-elle la sensibilité à la casse?
La solution
Les mots-clés SQL ne respectent pas la casse (SELECT, FROM, WHERE, etc.), mais sont souvent écrits en majuscules. Cependant, dans certaines configurations, les noms de table et de colonne sont sensibles à la casse. MySQL a une option de configuration pour l'activer / la désactiver. Les noms de table et de colonne sensibles à la casse sont généralement les noms par défaut sous Linux MySQL et insensibles à la casse sous Windows, mais le programme d’installation l’a demandé lors de l’installation. Pour MSSQL, cela dépend du paramètre de classement de la base de données.
Voici la page MySQL sur la sensibilité à la casse des noms
Voici l'article sur les collations pour MSSQL
Autres conseils
Cela ne concerne pas strictement le langage SQL, mais dans SQL Server, si le classement de votre base de données est sensible à la casse, tous les noms de table le sont.
Sur SQL Server c'est une option . Allumer c'est nul.
Je ne suis pas sûr de MySql.
Les identifiants et les mots réservés ne doivent pas être sensibles à la casse, bien que beaucoup suivent une convention consistant à utiliser des majuscules pour les mots réservés et la casse Pascal pour les identifiants.
Voir SQL-92 . 5.2
La spécification SQL92 indique que les identificateurs peuvent être cité, ou non cité. Si les deux côtés ne sont pas cotés, ils sont toujours insensibles à la casse, par ex. table_name == TAble_nAmE.
Cependant, les identificateurs cités sont sensibles à la casse, par exemple. "table_name" != "TAble_naME" Également basé sur la spécification, si vous souhaitez comparer des identificateurs non spécifiés avec des identificateurs entre guillemets, les identificateurs sans guillemet et entre guillemets peuvent être considérés comme identiques, si les caractères non entre guillemets sont en majuscule, par ex. TABLE_NAME == "TABLE_NAME", mais TABLE_NAME != "table_name" ou TABLE_NAME != "TAble_NaMe".
Voici la partie pertinente de la spécification (section 5.2.13):
13)A <regular identifier> and a <delimited identifier> are equiva-
lent if the <identifier body> of the <regular identifier> (with
every letter that is a lower-case letter replaced by the equiva-
lent upper-case letter or letters) and the <delimited identifier
body> of the <delimited identifier> (with all occurrences of
<quote> replaced by <quote symbol> and all occurrences of <dou-
blequote symbol> replaced by <double quote>), considered as
the repetition of a <character string literal> that specifies a
<character set specification> of SQL_TEXT and an implementation-
defined collation that is sensitive to case, compare equally
according to the comparison rules in Subclause 8.2, "<comparison
predicate>".
Notez que comme dans d’autres parties du standard SQL, toutes les bases de données ne suivent pas cette section intégralement. PostgreSQL, par exemple, stocke tous les identifiants non cités en minuscules au lieu de les en majuscules, donc table_name == "table_name" (ce qui est exactement le contraire de la norme). De plus, certaines bases de données sont sensibles à la casse à tout moment, ou la sensibilité à la casse dépend de certains paramètres de la base de données ou dépend de certaines propriétés du système, que le système de fichiers respecte ou non la casse.
Notez que certains outils de base de données peuvent envoyer des identificateurs entre guillemets. Par conséquent, dans les cas où vous mélangez des requêtes générées par un outil (comme une requête CREATE TABLE générée par Liquibase ou un autre outil de migration de base de données), des requêtes créées à la main (comme une requête). JDBC simple dans votre application), vous devez vous assurer que les cas sont cohérents, en particulier sur les bases de données où les identificateurs entre guillemets et entre guillemets sont différents (DB2, PostgreSQL, etc.)
D'après ce que je comprends, le standard SQL appelle à la non-distinction de la casse. Je ne pense cependant pas que les bases de données respectent complètement la norme.
MySQL a un paramètre de configuration dans le cadre de son " mode strict " (un sac contenant plusieurs paramètres qui rendent MySQL plus conforme aux normes) pour les noms de table sensibles à la casse ou insensibles. Indépendamment de ce paramètre, les noms de colonne ne sont toujours pas sensibles à la casse, bien que je pense que cela affecte la manière dont les noms de colonne sont affichés. Je pense que ce paramètre concerne l’ensemble des bases de données du SGBDR, bien que je m’efforce de le confirmer aujourd’hui (en espérant que la réponse sera non).
J'aime la façon dont Oracle s’en occupe beaucoup mieux. En SQL simple, les identificateurs tels que les noms de table et de colonne ne tiennent pas compte de la casse. Toutefois, si, pour une raison quelconque, vous souhaitez réellement utiliser une casse explicite, vous pouvez inclure l'identifiant entre guillemets (qui sont assez différents dans Oracle SQL des guillemets simples utilisés pour inclure les données de chaîne). Donc:
SELECT fieldName
FROM tableName;
interrogera nom de champ auprès de nom_table , mais
SELECT "fieldName"
FROM "tableName";
interrogera nom de champ auprès de nom de table .
Je suis presque sûr que vous pourriez même utiliser ce mécanisme pour insérer des espaces ou d'autres caractères non standard dans un identifiant.
Dans cette situation, si, pour une raison quelconque, vous jugiez souhaitable de citer explicitement les noms de table et de colonne explicitement insérés, vous auriez tout de même accès, mais je le déconseillais vivement.
Quand je travaillais tous les jours avec Oracle, je pensais que dans le code, je mettrais tous les mots clés Oracle SQL en majuscules et tous les identificateurs en minuscules. Dans la documentation, je mettrais tous les noms de table et de colonne en majuscule. C'était très pratique et lisible de pouvoir le faire (bien que parfois il soit difficile de taper autant de majuscules dans le code - je suis sûr que j'aurais pu trouver une fonctionnalité de l'éditeur pour aider, ici).
À mon avis, MySQL est particulièrement mauvais pour différer à ce sujet sur différentes plates-formes. Nous devons être en mesure de vider des bases de données sous Windows et de les charger sous UNIX. Si l'installateur de Windows avait oublié de mettre le SGBDR en mode sensible à la casse, cela créerait un désastre. (Pour être honnête, c’est en partie pour cette catastrophe que nos programmeurs ont pris la mauvaise décision, il y a longtemps, de s’en remettre à la casse de MySQL sous UNIX.) Les personnes qui ont écrit le programme d’installation Windows de MySQL l’ont vraiment rendu pratique. Il ressemblait beaucoup à Windows, et c’était bien de pouvoir donner aux gens une case à cocher indiquant & "Voulez-vous activer le mode strict et rendre MySQL plus conforme aux normes? &"; Mais il est très pratique pour MySQL de différer de manière si significative du standard, puis d’aggraver les choses en se retournant et en différant de son propre standard de facto sur différentes plates-formes. Je suis sûr que cela peut être aggravé par les différentes distributions Linux, car les emballeurs de différentes distributions ont probablement parfois incorporé leurs propres paramètres de configuration MySQL préférés.
Ici , une autre question SO qui entre dans les détails discuter si la sensibilité à la casse est souhaitable dans un SGBDR.
Non. MySQL n'est pas sensible à la casse, pas plus que le standard SQL. Il est courant d’écrire les commandes en majuscule.
Maintenant, si vous parlez de noms de table / colonne, alors oui, ils le sont, mais pas les commandes elles-mêmes.
Alors
SELECT * FROM foo;
est identique à
select * from foo;
mais pas le même que
select * from FOO;
J'ai trouvé ce billet de blog très utile (je ne suis pas l'auteur). Résumant (veuillez lire cependant):
... les identificateurs délimités sont sensibles à la casse (& "; nom_table &";! = & "nom_table &";), alors que les identificateurs non cités ne le sont pas et sont transformés en caractères supérieurs. case (nom_table = > NOM_Table).
Il a constaté que DB2, Oracle et Interbase / Firebird sont conformes à 100%:
PostgreSQL ... met en minuscule chaque identificateur non mis entre guillemets, au lieu de le mettre en majuscule. MySQL ... dépend du système de fichiers. SQLite et SQL Server ... les noms de table et de champ sont conservés lors de la création, mais ils sont complètement ignorés par la suite.
Les mots clés SQL ne sont pas sensibles à la casse.
Les noms de tables, de colonnes, etc., ont une distinction de casse qui dépend de la base de données - vous devriez probablement supposer qu’ils sont sensibles à la casse, sauf si vous le savez bien (dans de nombreuses bases de données, ils ne le sont pas; dans MySQL, les noms de table sont parfois sensibles à la casse. mais la plupart des autres noms ne le sont pas).
Comparaison des données avec =, > ;, < etc, a une connaissance de cas qui dépend des paramètres de classement qui sont utilisés sur la base de données individuelle, la table ou même la colonne en question. Il est toutefois normal de maintenir la cohérence des collations dans une base de données. Nous avons quelques colonnes qui doivent stocker des valeurs sensibles à la casse; ils ont une collation spécifiquement définie.
Je ne pense pas que SQL Server respecte la casse, du moins pas par défaut.
Lorsque je lance une requête manuelle via Management Studio, je me trompe tout le temps et l'accepte volontiers:
select cOL1, col2 FrOM taBLeName WheRE ...
