Raison pour laquelle Oracle est sensible à la casse?
Y a-t-il une raison pour laquelle Oracle est sensible à la casse et d'autres comme SQL Server et MySQL ne le sont pas par défaut?
Je sais qu'il existe des moyens d'activer/désactiver la sensibilité à la casse, mais il semble juste étrange qu'Oracle diffère des autres bases de données.
J'essaie également de comprendre les raisons de la sensibilité à la casse. Je peux voir où "Table" et "TaBlE" peuvent être considérés comme équivalents et non équivalents, mais y a-t-il un exemple où la sensibilité à la casse ferait réellement une différence?
Je suis un peu nouveau dans les bases de données et je suis actuellement en cours.
Par défaut, les identifiants Oracle (noms de table, noms de colonne, etc.) sont de la casse -insensible. Vous pouvez les rendre sensibles à la casse en utilisant des guillemets autour d'eux (par exemple: SELECT * FROM "My_Table" WHERE "my_field" = 1). Les mots clés SQL (SELECT, WHERE, JOIN, etc.) sont toujours insensibles à la casse.
D'un autre côté, les comparaisons de chaînes sont de la casse -sensible (par exemple: WHERE field='STRING' ne correspondra qu'aux colonnes où il est 'STRING') par défaut. Vous pouvez les rendre insensibles à la casse en définissant NLS_COMP et NLS_SORT aux valeurs appropriées (par exemple: LINGUISTIC et BINARY_CI, respectivement).
Remarque: Lorsque vous recherchez des vues de dictionnaire de données (par exemple:
dba_tables) les noms seront en majuscules si vous les avez créés sans guillemets, et les règles de comparaison de chaînes comme expliqué dans le deuxième paragraphe s'appliqueront ici.
Certaines bases de données (Oracle, IBM DB2, PostgreSQL, etc.) effectuent des comparaisons de chaînes sensibles à la casse par défaut, d'autres ne respectent pas la casse (SQL Server, MySQL, SQLite). Ce n'est en aucun cas standard, alors soyez conscient de vos paramètres de base de données.
Oracle traite réellement les noms de champ et de table d'une manière qui ne respecte pas la casse, sauf si vous utilisez des guillemets autour des identificateurs. Si vous créez une table sans guillemets autour du nom, par exemple CREATE MyTable ..., le nom de la table résultante sera converti en majuscules (c'est-à-dire MYTABLE) et sera traité de manière insensible à la casse. SELECT * de MYTABLE, SELECT * de MyTable, SELECT * de myTabLe correspondront tous à MYTABLE (notez l'absence de guillemets autour du nom de la table). Voici un Nice article sur ce problème qui traite de ce problème plus en détail et compare les bases de données.
Si je devais deviner, je dirais pour des raisons de compatibilité historique/rétrocompatible.
Oracle est sorti pour la première fois en 1977, et il était probablement coûteux en termes de calcul avec la technologie à l'époque de faire le travail supplémentaire pour les recherches non sensibles à la casse, donc ils ont juste opté pour des correspondances exactes.
Gardez également à l'esprit que pour SQL Server, la sensibilité à la casse est basée sur le classement. Le classement par défaut est insensible à la casse - mais cela pourrait être modifié pour être sensible à la casse. Un exemple similaire explique pourquoi les bases de données Oracle par défaut utilisent un jeu de caractères d'Europe occidentale lorsque UTF est requis pour les applications globales qui utilisent des caractères non ASCII? Je pense que ce n'est qu'une préférence de fournisseur.
Pour certaines applications, la sensibilité à la casse est importante et pour d'autres non. Quel que soit le SGBD que vous utilisez, les exigences commerciales doivent déterminer si vous avez besoin ou non de la casse. Je ne m'inquiéterais pas trop du "défaut".