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".

[Vincent Rogier]

comme pomalaix, je pense que c'est une très mauvais idée...

De plus l'exemple DDL que tu fournis est très mauvais car tu mélanges ton "CamelCase" avec des "_" que justemement tu invoques pour justifier ton choix

L'emploi de nom sensible à la casse pour les objets Oracle va être une contrainte, une lourdeur, une source de bug, d'incident pendant le développement, le déploiement et la maintenance sur des années de la base/application.
Les futurs mainteneurs de la base/application te maudiront, crois moi !

Les raisons que tu invoques pour moi sont des broutilles au vu de la merde qu'un tel schéma peut apporter à la vie l'application et à sa maintenance par des développeurs, des DBA, etc...

Maintenant cela n'engage que moi.... Mais d'expérience, c'est une très mauvaise idée.

[Invité]

De même, par expérience, c'est se mettre des bâtons dans les roues pour une exigence très contestable.
La charge de travail supplémentaire engendrée par ce détail est trop importante pour être valable.

[Drag]

Bonjour,

Et bien voilà qui donne à réfléchir... Je suis tout de même surpris par certains points.

Générer les query avec java
Qu'y a-t-il de mal à utiliser des objets java pour construire les requêtes SQL? Ca évite de faire de bêtes erreurs de syntaxe, de frappe et ça définit clairement quelles opérations sont permises sur la DB. Effectivement, ça permet également de modifier la syntaxe des queries lorsqu'on change de DB... mais où est le mal? Lorsqu'au début du projet, on ne sait pas quelle DB sera derrière, c'est un moyen souple de pouvoir changer de base de données en changeant un minimum de code.

Combiner CamelCase et "_" dans des cas techniques bien précis
L'emploi des CamelCase avec des "_" ne me plait pas non plus, ce sera absolument évité à l'intérieur même d'un nom de table. Cependant, je ne vois pas en quoi cela est dérangeant lorsqu'il s'agit de données techniques, commes les indexes par exemple. Ce sont des cas clairs et bien définis, et on garde là-dessus les habitudes Oracle. A la limite, ça me plait bien "MaTableExemple_PK": du premier coup d'oeil, je sais si il s'agit d'un nom de table ou pas. Du premier coup d'oeil, je peux distinguer quelle est la partie plus "fonctionnelle" du nom, et quelle est la partie plus technique. (Je me souviens d'ailleurs avoir vu un site de "best practices" SQL server où ils donnaient des exemples du genre pour des noms de tables: GRP_CamelCase. Je n'ai pas dit que ce site avait la science infuse... je devrais le retrouver. [EDIT]J'ai retouvé le site parlant des conventions de nommage. Effectivement, il est bien indiqué que ce ne sont que les préférences personnelles de l'auteur, même si j'ai l'impression que le CamelCase commence à rentrer de manière significative dans le monde DB: http://vyaskn.tripod.com/object_naming.htm[/EDIT])

Charge de travail supplémentaire engendrée par les quotes
Vu qu'aucun query n'est écrit à la main dans l'application, quelle serait la charge de travail supplémentaire? C'est le générateur de query qui se charge de mettre les ", et lui en théorie ne se trompe pas...
Le seul ennui que je vois, c'est qu'il ne faudra pas oublier de mettre les quotes lorsqu'on fait des query à la main hors application, pour consulter la DB.


Merci en tout cas des retours sur le sujet, c'est le genre de réponses que j'attendais. Cependant, pour ceux qui ont déjà expérimenté des problèmes avec les noms de table en CamelCase, est-il possible d'avoir un ou deux exemples concrets de problèmes rencontrés? Pour quelles raisons vous étiez-vous lancé là-dedans? Un projet récupéré malgré vous? Parce que j'ai toujours du mal à comprendre quel genre de bugs ou d'incidents pourraient se produire à cause de ça. Du point de vue performance, c'est identique je suppose?

J'avoue que pour l'instant, ce qui m'inquiète point de vue lourdeur, ce serait plutôt le reenginering demandé pour transformer tous les noms de la DB depuis le CamelCase vers du uppercase avec des "_". Si il le faut, il le faut, mais concrètement, je ne sais pas ce que j'y gagnerais, même sur le long terme...

[OracleFan]

Salut Drag,

Si je peux me permettre mon intervention à deux francs...

Il n'y a aucun mal à vouloir tout gérer au niveau de ton application Java. Théoriquement, tu as raison. Mais en pratique, les développeurs savent à l'avance quel est le SGBD cible et utilise au maximum les ressources/fonctionnalités de ce SGBD.

Ensuite, par rapport à la casse de tes "objets".
Je vois pas pourquoi tu ne peux pas créer tes objets en utilisant des noms comme: MyFirstTable, MyFirstIndex, MyLongNameView, MyMaterializedView...

La casse est CamelCase, n'est-ce pas? Oracle la stockera en base en majuscule, mais toi, quand tu y accèdes, tu réutilises tes noms en CamelCase. Utilise juste dans le nom de tes tables des caractères et des chiffres ([a-z][A-Z][0-9]).

Ensuite, je pense que tu te poses un faux problème. Si tout est/sera géré dans une application Java pourquoi se prendre la tête? Mais je doute que tu puisses changer de système aussi simplement que tu ne le dises si tu commences avec ce genre de spécificités (je doute fort que tout les SGBD acceptent de donner des noms comme "1) [Voici un nom de table]", "2) {Un autre nom de table}!". A ta place, j'appliquerai la méthode KISS (keep it simple, stupid) ;-)

[mnitu]

...
Générer les query avec java
Qu'y a-t-il de mal à utiliser des objets java pour construire les requêtes SQL? Ca évite de faire de bêtes erreurs de syntaxe, de frappe et ça définit clairement quelles opérations sont permises sur la DB. Effectivement, ça permet également de modifier la syntaxe des queries lorsqu'on change de DB... mais où est le mal? Lorsqu'au début du projet, on ne sait pas quelle DB sera derrière, c'est un moyen souple de pouvoir changer de base de données en changeant un minimum de code.
...

C’est exactement le problème. Le SGBD X est renvoyée en arrière 10 ans pour être compatible avec le SGBD Y, dpv de votre application. C’est le lit de Procuste des bases des données, un désastre !
Le SQL n’est rien en comparaison avec les différences importantes qui existent entre divers SGBD. Petit exemples : les variables de liaisons. Et on ne parle pas d’optimisation ni des différences en termes d’accès concurrent, des niveaux d’isolation de la transaction, etc.

[Drag]

OracleFan > Même si tout passe par java, je n'ai pas forcément envie de me retrouver concrètement avec des noms tels que MYFIRSTTABLE, MYFIRSTINDEX, MYLONGNAMEVIEW, MYMATERIALIZEDVIEW...
Dans mon cas, on ne savait pas à l'avance quel serait le SGBD... on a donc essayé de faire le plus standard possible. L'erreur était de penser qu'utiliser la casse était standard, vu que Oracle ne la digère qu'à moitié.

Le but n'est pas d'avoir une application utilisable avec tous les SGBD, loin de là, mais de pouvoir migrer le plus simplement possible si cela s'avère nécessaire. En étant KISS justement, sans essayer d'utiliser de spécificités particulières de tel ou tel SGBD lorsque ce n'est pas nécessaire. Pour l'instant, ça fonctionne en HSQL, en MySQL et (presque complètement) en Oracle. Vu que le choix est fait maintenant, si un jour on a besoin de fonctionnalités nouvelles liées à Oracle qui impacteraient directement le code (ce qui m'étonnerait), on ne se fatiguera pas à maintenir ces dernières pour les autres DB. En attendant, commencer par MySQL était gratuit, simple à mettre en place, et pas bien compliqué à migrer...

mnitu > Si on sait qu'on a besoin de faire uniquement des opérations simples, je n'ai pas l'impression que les différences entre SGBD sont vraiment si cruciales. Tant que ce n'est pas réellement utile/efficace, je ne vois pas d'ailleurs l'intérêt d'employer les fonctionnalités particulières à un SGBD. (A part peut-être pour apprendre à "maitriser" un SGBD X, une connaissance qui peut servir.) Evidemment, ce n'est peut-être pas un message approprié sur un forum Oracle, où on retrouve surement des experts qui ont trouvé de nombreuses solutions à de nombreux problèmes dans leur carrière justement grâce aux nombreuses spécificités d'Oracle. (Qui est solide SGBD, ça on peut lui reconnaitre... même si c'est parfois ennuyeux de se rendre compte qu'il traine avec lui certains "détails", comme cette limitation à 30 caractères pour les noms ou la non-prise en compte de la casse...)

[mnitu]

Pourriez-vous définir les "opérations simples" que vous envisages d'utiliser ?

[Drag]

Posée comme ceci, ce n'est pas forcément une question évidente.
create, insert, update, delete et select?

Selon les besoins, ces opérations basiques peuvent rapidement se complexifier et se particulariser, ce n'est donc évidemment pas ceci qui garantit que les opérations sont simples. Une opération simple est déterminée par les données que l'on doit gérer et les traitements que l'on doit effectuer dessus.

A noter que je n'ai pas dit non plus que quoi que ce soit était miraculeux. Même si passer de MySQL à Oracle n'était pas difficile grâce à la volonté de garder les opérations simples exprimée simplement, ce n'est pas pour autant que ça n'a pas demandé du travail (certains noms réservés en oracle, clob traités différemment, etc.) ... mais ce travail fut ciblé et limité.

[Vincent Rogier]

* la remarque des nom réservés est un non sens ! chaque langage a ses mots clés, le SQL aussi. Oracle existe depuis 30 ans. Il n'a pas attendu les normes ISO SQL. Tu cites "number"... qui est un type de base Oracle et donc un mot clé comme "table", etc... MySql possède aussi des mots clés qui pourrait être utilisé comme bon vouloir sur Oracle car ils n'en sont pas, etc... Donc, laisse tomber cet argument sur les mots réservé.
* Tu parles de la gestion "différente" des blob ? Oracle les a introduit avant le standard et supporte le standard concernant les blob, etc...
* Les limites de noms ? c'est sur qu'un nom de table de 80 caractère, c'est plus lisible

Mais bon, laissons tout ça de coté

Plusieurs personne expérimentées t’ont déconseillé de gérer des noms de tables sensible à la casse. Maintenant à toi de voir.

Prend ta décision et tiens toi y

[Drag]

On est bien d'accord! Cependant, le choix est délicat... je me sens toujours aussi indécis qu'au moment de créer ce post.

Certains disent qu'il n'y a pas de contre-indications, d'autres que je vais le regretter à fond... mais au final, je n'ai toujours pas compris concrètement quand et pourquoi je rencontrerai des problèmes avec l'utilisation de quotes. (Je n'ai aucun doute sur le fait que ceux qui me conseillent de ne pas mettre des quotes ont dû faire face à de vrais ennuis... mais sans doute que les conditions étaient différentes?)
Le bon sens voudrait donc que j'utilise les quotes, vu qu'Oracle les propose et que ça demanderait moins de travail à mettre en place dans ce cas bien précis. (Je ne conseillerai à personne qui travaille en Oracle de mettre des quotes...) Ca n'empêche que j'ai toujours une crainte bien réelle...


PS: Que ce soit pour les mots réservés, pour les clobs ou pour la longueur des noms de tables, je ne les ai pas employés comme arguments de quoi que ce soit! Je les citais simplement comme exemple de travail qu'on doit prendre en compte pour passer de MySQL à Oracle, ni plus ni moins.
(Ceci dit, tant qu'on y est, 30 caractères c'est quand même limite, surtout si on doit prendre en compte les underscores et les suffixes. Je préfère une limite de 80 caractères utilisée intelligemment -et donc parfois pas du tout- plutôt qu'une limite de 30 caractères qui empêche de temps en temps de respecter des conventions de nommage claires et efficaces. Mais là n'est pas le sujet...)

[Vincent Rogier]

Le seul argument que nous avons sont l'empirisme et le pragmatisme issus de nos expérience de développement.

Pour des gens n'utilisant pas des ORM, des noms de tables ou d'objets à rallonge et sensibles à la casse sont une vraie plaie et source de bugs.

Maintenant, si tu mises à 100% sur des ORM et le fait que personne n'écrira de requête à la main, alors oui, utilise des noms d'objets sensibles à la casse. Dans le cas contraire, tu t'en mordra les doigts

[mnitu]

Posée comme ceci, ce n'est pas forcément une question évidente.
create, insert, update, delete et select?

Selon les besoins, ces opérations basiques peuvent rapidement se complexifier et se particulariser, ce n'est donc évidemment pas ceci qui garantit que les opérations sont simples. Une opération simple est déterminée par les données que l'on doit gérer et les traitements que l'on doit effectuer dessus.

A noter que je n'ai pas dit non plus que quoi que ce soit était miraculeux. Même si passer de MySQL à Oracle n'était pas difficile grâce à la volonté de garder les opérations simples exprimée simplement, ce n'est pas pour autant que ça n'a pas demandé du travail (certains noms réservés en oracle, clob traités différemment, etc.) ... mais ce travail fut ciblé et limité.

Techniquement, il n'y pas de gros problèmes pour l’utilisation des quottes surtout quand les requêtes sont générées. Il y des difficultés pour les requêtes ad-hoc mais ces difficultés peuvent être contournées à la limite.

Mais, le vrai problème n'est pas la. Je vous recommande de lire "Database Independence" (page 37 et après).

[OracleFan]

Salut Drag,

Je sais pas si tu as lu la doc d'Oracle, mais il est clairement indiqué ceci:

Note:
Oracle does not recommend using quoted identifiers for database object names. These quoted identifiers are accepted by SQL*Plus, but they may not be valid when using other tools that manage database objects.

Ensuite, as-tu vérifié que ton driver JDBC supporte les noms entre guillemets? Peut-être qu'il acceptera des espaces, mais je doute qu'il accepte des ? ou des : dans les noms sans rouspéter.