Discussion :

[Drag]

Bonjour,

Par défaut, Oracle n'est pas sensible à la casse pour tout ce qui n'est pas data (nom de table, de column, d'index, de séquence...) Oracle met d'ailleurs carrément tout ça en uppercase par défaut. Il y a moyen que cela devienne case sensitive si on utilise des quotes ("..."). Mais dans ce cas, il ne faut jamais les oublier, ne serait-ce que pour faire un petit SELECT à la main.

Je compte utiliser ces quotes, histoire d'avoir tout en case sensitive, pour diverses raisons. (Schema de la DB initialement pensé avec des noms "style java", gain de caractères (pas de caractère _), habitude, ...)
Ca donne un look du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
CREATE TABLE "testCase"("idCase" integer not null, CONSTRAINT "testCase_PK" PRIMARY KEY("idCase"), "loginCase" VARCHAR2(30) not null, UNIQUE("loginCase"), "passwordCase" VARCHAR2(50) not null)
CREATE SEQUENCE "testCase_SEQ" MINVALUE 1 NOCYCLE
CREATE OR REPLACE TRIGGER  "testCase_TID"

Cependant, selon vous, est-ce une bonne idée? Voyez-vous des problèmes qui pourraient surgir suite à ce choix? Des subtilités auquelles on ne pense pas toujours de premier abord?


Merci beaucoup.

[Waldar]

Non pas de contre indication particulière, mais si vous tapez beaucoup de SQL à la main vous pourriez le regretter si vous n'utilisez pas un outil SQL un peu avancé.

[pachot]

Bonjour,
Le problème peut venir de scripts, outils de monitoring,... qui ont été conçus en pensant que tout est uppercase.
Cordialement,
Franck.

[Drag]

Lorsqu'on parle de scripts ou d'outils de monitoring qui pourraient rencontrer des problèmes, il s'agit d'outils habituels, ou alors de programmes que l'on aurait développé personnellement pour son projet?


A vrai dire, pour tous les query rencontrés, je passe par l'intermédiaire d'objets java qui reçoivent les données de base du query et construisent les transactions à effectuer pour les soumettre à la DB. Ces classes gèrent donc facilement les "petites" différences que l'ont peut rencontrer dans les requêtes en fonction la DB utilisée. Initialement, le projet a commencé avec MySql. (L'idée est d'employer du SQL standard tant que c'est possible... et jusqu'ici, ça va plus ou moins.)

Pour certaines restrictions Oracle, il n'y a pas le choix: il faut effectuer certains changement à la main (noms de table de plus de 26 caractères, noms de colonnes interdits tels que "number", "sequence", etc...)
Mais pour ce qui est "case sensitive", je n'ai pas vraiment envie d'aller rajouter des underscores partout dans les noms de tables et colonnes... (D'autant plus que des jolis noms en CamelCase, ça me semble être l'avenir, non? ;-) Même si je n'ai rien contre la notion Oracle, tant que tout est cohérent.)

Enfin bref, merci pour vos réponses. Ça me conforte dans l'idée que je peux rajouter automatiquement des quotes partout où c'est nécessaire, sans pour autant prendre trop de risques.
(Même si devoir mettre des quotes dans les query qui seront inévitablement fait à la main à un moment ou à un autre, ça me refroidissait au début...)

[pachot]

il s'agit d'outils habituels, ou alors de programmes que l'on aurait développé personnellement pour son projet?

Je pensais aux 2. Mais rien de bien grave, il faut juste y penser si tu rencontre un problème.

[Pomalaix]

Pour moi c'est à éviter. C'est contraire à tous les usages sous Oracle et ça ne fait pas partie des réflexes. Il est à craindre que certains outils ne sachent pas gérer cette subtilité.
Rajouter les guillemets partout va être assez pénible, et bien entendu si on les oublie, on ne retrouvera pas ses petits dans le dictionnaire de données.
En deux mots : à fuir !

[mnitu]

Pour moi c'est à éviter. C'est contraire à tous les usages sous Oracle et ça ne fait pas partie des réflexes. Il est à craindre que certains outils ne sachent pas gérer cette subtilité.
Rajouter les guillemets partout va être assez pénible, et bien entendu si on les oublie, on ne retrouvera pas ses petits dans le dictionnaire de données.
En deux mots : à fuir !

Ca ne pose pas des problèmes pour n'importe quel outil sérieux fourni par Oracle ou autres.
Moi je fuirai des applications multi-base écrites en Java où "ces classes gèrent donc facilement les "petites" différences que l'ont peut rencontrer dans les requêtes en fonction la DB utilisée".