La syntaxe SQL est-elle sensible à la casse?

Est sensible à la casse SQL. J'ai utilisé MySQL et SQL Server qui semblent être sensibles à la casse. Est-ce toujours le cas? La norme définit-elle la sensibilité à la casse?

Les mots - clés SQL sont insensibles à la casse ( SELECT, FROM, WHERE, etc.), mais sont souvent écrites 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 / le désactiver. Généralement, les noms de table et de colonne sensibles à la casse sont ceux par défaut sous Linux MySQL et insensibles à la casse par défaut sous Windows, mais maintenant le programme d'installation a posé des questions à ce sujet lors de la configuration. Pour MSSQL, c'est une fonction 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 dans MSDN sur les classements pour MSSQL

Ce n'est pas strictement du langage SQL, mais dans SQL Server si votre classement de base de données est sensible à la casse, tous les noms de table sont sensibles à la casse.

Dans Sql Server, c'est une option . L'allumer est nul.

Je ne suis pas sûr de MySql.

Les identificateurs et les mots réservés ne doivent pas être sensibles à la casse, bien que beaucoup suivent une convention pour utiliser des majuscules pour les mots réservés et la casse Pascal pour les identificateurs.

Voir SQL-92 Sec. 5.2

La spécification SQL92 indique que les identificateurs peuvent être entre guillemets ou non. Si les deux côtés ne sont pas cités, ils sont toujours insensibles à la casse, par exemple table_name == TAble_nAmE.

Cependant, les identifiants cités sont sensibles à la casse, par exemple "table_name" != "TAble_naME". Également basé sur la spécification si vous souhaitez comparer les identifiants non supprimés avec ceux cités, les identifiants non cités et cités peuvent être considérés comme identiques, si les caractères non cités sont en majuscules, par exemple 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 pour les autres parties du standard SQL, toutes les bases de données ne suivent pas entièrement cette section. PostgreSQL, par exemple, stocke tous les identifiants non cotés en minuscules au lieu de majuscules, donc table_name == "table_name"(ce qui est exactement l'opposé de la norme). De plus, certaines bases de données ne respectent pas la casse tout le temps, ou la sensibilité à la casse dépend d'un paramètre de la base de données ou dépend de certaines des propriétés du système, généralement si le système de fichiers est sensible à la casse ou non.

Notez que certains outils de base de données peuvent envoyer des identificateurs cités tout le temps, donc 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), avec des requêtes faites à la main (comme une simple sélection JDBC dans votre application), vous devez vous assurer que les cas sont cohérents, en particulier sur les bases de données où les identifiants entre guillemets et non entre guillemets sont différents (DB2, PostgreSQL, etc.)

Ma compréhension est que le standard SQL appelle à l'insensibilité à la casse. Cependant, je ne pense 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 à main de 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 respectent toujours pas la casse, bien que je pense que cela affecte la façon dont les noms de colonne sont affichés. Je crois que ce paramètre est à l'échelle de l'instance, dans toutes les bases de données au sein de l'instance RDBMS, bien que je fasse des recherches aujourd'hui pour le confirmer (et j'espère que la réponse est non).

J'aime la façon dont Oracle gère cela beaucoup mieux. En SQL simple, les identificateurs comme les noms de table et de colonne ne respectent pas la casse. Cependant, si pour une raison quelconque vous souhaitez vraiment obtenir une casse explicite, vous pouvez placer l'identifiant entre guillemets doubles (qui sont assez différents dans Oracle SQL des guillemets simples utilisés pour entourer les données de chaîne). Alors:

SELECT fieldName
FROM tableName;

interrogera le nom du champ à partir du nom de la table , mais

SELECT "fieldName"
FROM "tableName";

interrogera fieldName à partir de tableName .

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 trouviez souhaitable que les noms de table et de colonne soient placés dans un cas explicite, il était disponible pour vous, mais c'était toujours quelque chose contre lequel je mettrais en garde.

Ma convention lorsque j'utilisais Oracle quotidiennement était que dans le code, je mettrais tous les mots clés Oracle SQL en majuscules et tous les identifiants en minuscules. Dans la documentation, je mettrais tous les noms de table et de colonne en majuscules. C'était très pratique et lisible de pouvoir le faire (bien que parfois difficile de taper autant de majuscules dans le code - je suis sûr que j'aurais pu trouver une fonctionnalité d'édition 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 les bases de données sous Windows et de les charger dans UNIX, et cela est un désastre si le programme d'installation sur Windows a oublié de mettre le SGBDR en mode sensible à la casse. (Pour être honnête, une des raisons pour lesquelles il s'agit d'un désastre est que nos codeurs ont pris la mauvaise décision, il y a longtemps, de s'appuyer sur la sensibilité à la casse de MySQL sous UNIX.) Les personnes qui ont écrit le programme d'installation de Windows MySQL l'ont rendu très pratique et Comme Windows, et c'était génial de proposer aux gens une case à cocher pour dire "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 significative de la norme, et ensuite aggraver les choses en se retournant et en différant de sa propre norme de facto sur différentes plates-formes. Je suis sûr que sur différentes distributions Linux, cela peut être encore plus compliqué, car les packagers pour différentes distributions ont probablement parfois incorporé leurs propres paramètres de configuration MySQL préférés.

Voici une autre question SO qui permet de discuter si la sensibilité à la casse est souhaitable dans un SGBDR.

Non. MySQL n'est pas sensible à la casse, ni la norme SQL. C'est juste une pratique courante d'écrire les commandes en majuscule.

Maintenant, si vous parlez de noms de table / colonne, alors oui, mais pas les commandes elles-mêmes.

Alors

SELECT * FROM foo;

est le même que

select * from foo;

mais pas la même chose que

select * from FOO;

J'ai trouvé cet article de blog très utile (je ne suis pas l'auteur). En résumé (veuillez lire, cependant):

... les identificateurs délimités sont sensibles à la casse ("nom_table"! = "nom_table"), tandis que les identificateurs non cités ne le sont pas et sont transformés en majuscules (nom_table => NOM_TABLIER).

Il a découvert que DB2, Oracle et Interbase / Firebird sont 100% conformes:

PostgreSQL ... met en minuscule chaque identifiant non cité, au lieu de le mettre en majuscule. MySQL ... dépend du système de fichiers. SQLite et SQL Server ... la casse des noms de table et de champ sont conservés à la création, mais ils sont complètement ignorés par la suite.

Je ne pense pas que SQL Server soit sensible à la casse, du moins pas par défaut.

Lorsque j'interroge manuellement via Management Studio, je gâche tout le temps et il l'accepte joyeusement:

select cOL1, col2 FrOM taBLeName WheRE ...

Les mots clés SQL sont eux-mêmes insensibles à la casse.

Les noms des tables, des colonnes, etc. ont une sensibilité à la casse qui dépend de la base de données - vous devez probablement supposer qu'ils sont sensibles à la casse, sauf si vous le savez autrement (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 les noms ne le sont pas).

La comparaison des données à l'aide de =,>, <etc, a une connaissance de la casse 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 cependant normal de conserver un classement assez cohérent dans une base de données. Nous avons quelques colonnes qui doivent stocker des valeurs sensibles à la casse; ils ont un classement spécifiquement défini.

Ayez le meilleur des deux mondes

De nos jours, vous pouvez simplement écrire toutes vos instructions SQL en minuscules et si vous avez besoin de le formater, installez simplement un plugin qui le fera pour vous. Ceci n'est applicable que si votre éditeur de code dispose de ces plugins. VSCode a de nombreuses extensions qui peuvent le faire.