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 bizarre qu'oracle diffère des autres bases de données.
J'essaie aussi 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 un la différence?
Je suis un peu nouveau dans les bases de données et je prends actuellement une classe.
5 réponses
Par défaut, les identifiants Oracle (noms de tables, noms de colonnes, etc.) sontinsensibles à la casse . Vous pouvez les rendre sensibles à la casse en utilisant des guillemets autour d'eux (par exemple: SELECT * FROM "My_Table" WHERE "my_field" = 1). Mots-clés SQL (SELECT, WHERE, JOIN, etc.) sont toujours insensibles à la casse.
D'autre part, les comparaisons de chaînes sont sensibles à la casse (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 demandez 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.) effectuera des comparaisons de chaînes sensibles à la casse par défaut, d'autres non sensibles à la casse (SQL Server, MySQL, SQLite). Ce n'est pas standard par tous les moyens, alors soyez conscient de quels sont vos paramètres de base de données.
Oracle traite réellement les noms de champs et de tables d'une manière insensible à 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 table résultant sera converti en majuscules (c'est-à-dire MYTABLE) et sera traité de manière insensible à la casse. SELECT * from MYTABLE, SELECT * from MyTable, SELECT * from myTabLe correspondra à MYTABLE (notez l'absence de guillemets autour du nom de la table). Voici un bel article sur cette question qui traite de cette question plus en détail et compare les bases de données.
Gardez à l'esprit aussi pour SQL Server la sensibilité à la casse est basée sur le classement. Le classement par défaut est insensible à la casse - mais cela peut être modifié pour être sensible à la casse. Un exemple similaire est pourquoi les bases de données Oracle par défaut utilisent-elles 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 c'est juste une préférence de fournisseur.
Si je devais deviner, je dirais pour des raisons historiques/rétrocompatibilité.
Oracle est sorti pour la première fois en 1977, et il était probablement coûteux de calculer avec la technologie à l'époque pour faire le travail supplémentaire pour les recherches insensibles à la casse, donc ils ont juste opté pour des Correspondances exactes.
Pour certaines applications, la sensibilité à la casse est importante et pour d'autres non. quel que soit le SGBD que vous utilisez, les exigences métier doivent déterminer si vous avez besoin de sensibilité à la casse ou non. Je ne m'inquiéterais pas trop du "défaut".