La syntaxe SQL est-elle sensible à la casse ?

Question

SQL est-il 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 ?

Answer 1

Les mots-clés SQL sont insensibles à la casse ( SELECT , FROM , WHERE etc.), mais ils sont souvent écrits en majuscules. Cependant, dans certaines configurations, les noms de tables et de colonnes sont sensibles à la casse. MySQL a une option de configuration pour l'activer/désactiver. Habituellement, les noms de tables et de colonnes sensibles à la casse sont la valeur par défaut de MySQL sous Linux et la non sensibilité à la casse était la valeur par défaut sous Windows, mais maintenant l'installateur demande ce point lors de l'installation. Pour MSSQL, c'est une fonction du paramètre de collation de la base de données.

Voici le Page MySQL sur la sensibilité des noms à la casse

Voici le article dans MSDN sur les collations pour MSSQL

Answer 2

Il ne s'agit pas d'un langage strictement SQL, mais dans SQL Server, si la collation de votre base de données est sensible à la casse, alors tous les noms de table sont sensibles à la casse.

Answer 3

Dans Sql Server c'est une option . L'allumer, ça craint.

Je ne suis pas sûr pour MySql.

Answer 4

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

Ver SQL-92 Sec. 5.2

Answer 5

Je crois savoir que la norme SQL prévoit l'insensibilité à la casse. Je ne pense pas que les bases de données suivent complètement la norme, cependant.

MySQL dispose d'un paramètre de configuration dans le cadre de son "mode strict" (un ensemble de plusieurs paramètres qui rendent MySQL plus conforme aux normes) pour les noms de table sensibles ou non à la casse. Indépendamment de ce paramètre, les noms de colonnes sont toujours insensibles à la casse, bien que je pense que cela affecte la façon dont les noms de colonnes sont affichés. Je pense que ce paramètre est valable pour toutes les bases de données de l'instance du SGBDR, mais je fais des recherches aujourd'hui pour le confirmer (et j'espère que la réponse est non).

J'aime beaucoup mieux la façon dont Oracle gère cela. En SQL classique, les identificateurs tels que les noms de tables et de colonnes sont insensibles à la casse. Toutefois, si, pour une raison quelconque, vous souhaitez vraiment obtenir une casse explicite, vous pouvez placer l'identificateur entre guillemets doubles (qui sont très différents dans Oracle SQL des guillemets simples utilisés pour contenir les données de la chaîne). Ainsi :

SELECT fieldName
FROM tableName;

interrogera nom du champ de nom de l'onglet mais

SELECT "fieldName"
FROM "tableName";

interrogera nom du champ de nom de la 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 ou une autre vous trouviez que les noms de tables et de colonnes explicites étaient souhaitables, vous pouviez le faire, mais je vous déconseille fortement de le faire.

Lorsque j'utilisais Oracle au quotidien, ma convention était la suivante : dans le code, je mettais tous les mots-clés SQL Oracle en majuscules et tous les identifiants en minuscules. Dans la documentation, je mettais tous les noms de tables et de colonnes en majuscules. C'était très pratique et lisible de pouvoir faire cela (bien que parfois pénible de taper autant de majuscules dans le code -- je suis sûr que j'aurais pu trouver une fonction d'éditeur pour m'aider, ici).

À mon avis, MySQL est particulièrement mauvais pour ce qui est des différences entre les plateformes. Nous devons être en mesure de vider des bases de données sous Windows et de les charger sous UNIX, et le faire est un désastre si l'installateur sous Windows a oublié de mettre le SGBDR en mode sensible à la casse. (Pour être juste, une partie de la raison pour laquelle c'est un désastre est que nos codeurs ont pris la mauvaise décision, il y a longtemps, de se fier à la sensibilité à la casse de MySQL sur UNIX). Les personnes qui ont écrit le programme d'installation de MySQL pour Windows l'ont rendu très pratique et conforme à Windows, et c'était formidable de pouvoir donner 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 s'écarter de manière aussi significative du standard, puis d'aggraver les choses en s'écartant de son propre standard de facto sur différentes plateformes. Je suis sûr que sur les différentes distributions Linux, cela peut être encore aggravé, car les empaqueteurs des différentes distributions ont probablement parfois incorporé leurs propres paramètres de configuration MySQL préférés.

Ici Il y a une autre question de l'OS qui permet de discuter si la sensibilité à la casse est souhaitable dans un SGBDR.