IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 Oracle Discussion :

Oracle en "case sensitive" (pour ce qui n'est pas data): bonne idée?


Sujet :

Oracle

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2004
    Messages : 61
    Points : 34
    Points
    34
    Par défaut Oracle en "case sensitive" (pour ce qui n'est pas data): bonne idée?
    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.

  2. #2
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 814
    Points
    17 814
    Par défaut
    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é.

  3. #3
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    Le problème peut venir de scripts, outils de monitoring,... qui ont été conçus en pensant que tout est uppercase.
    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2004
    Messages : 61
    Points : 34
    Points
    34
    Par défaut
    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...)

  5. #5
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    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.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  6. #6
    Rédacteur

    Homme Profil pro
    Consultant / formateur Oracle et SQL Server
    Inscrit en
    Décembre 2002
    Messages
    3 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant / formateur Oracle et SQL Server

    Informations forums :
    Inscription : Décembre 2002
    Messages : 3 460
    Points : 8 073
    Points
    8 073
    Par défaut
    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 !
    Consultant / formateur Oracle indépendant
    Certifié OCP 12c, 11g, 10g ; sécurité 11g

    Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration

  7. #7
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Citation Envoyé par Pomalaix Voir le message
    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".

  8. #8
    Rédacteur
    Avatar de Vincent Rogier
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    2 373
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 373
    Points : 5 307
    Points
    5 307
    Par défaut
    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.
    Vincent Rogier.

    Rubrique ORACLE : Accueil - Forum - Tutoriels - FAQ - Livres - Blog

    Vous voulez contribuer à la rubrique Oracle ? Contactez la rubrique !

    OCILIB (C Driver for Oracle)

    Librairie C Open Source multi-plateformes pour accéder et manipuler des bases de données Oracle

  9. #9
    Invité
    Invité(e)
    Par défaut
    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.

  10. #10
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2004
    Messages : 61
    Points : 34
    Points
    34
    Par défaut
    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...

  11. #11
    Membre habitué
    Inscrit en
    Mai 2010
    Messages
    107
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 107
    Points : 132
    Points
    132
    Par défaut
    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) ;-)

  12. #12
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Citation Envoyé par Drag Voir le message
    ...
    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.

  13. #13
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2004
    Messages : 61
    Points : 34
    Points
    34
    Par défaut
    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...)

  14. #14
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Pourriez-vous définir les "opérations simples" que vous envisages d'utiliser ?

  15. #15
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2004
    Messages : 61
    Points : 34
    Points
    34
    Par défaut
    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é.

  16. #16
    Rédacteur
    Avatar de Vincent Rogier
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    2 373
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 373
    Points : 5 307
    Points
    5 307
    Par défaut
    * 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
    Vincent Rogier.

    Rubrique ORACLE : Accueil - Forum - Tutoriels - FAQ - Livres - Blog

    Vous voulez contribuer à la rubrique Oracle ? Contactez la rubrique !

    OCILIB (C Driver for Oracle)

    Librairie C Open Source multi-plateformes pour accéder et manipuler des bases de données Oracle

  17. #17
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2004
    Messages : 61
    Points : 34
    Points
    34
    Par défaut
    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...)

  18. #18
    Rédacteur
    Avatar de Vincent Rogier
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    2 373
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 373
    Points : 5 307
    Points
    5 307
    Par défaut
    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
    Vincent Rogier.

    Rubrique ORACLE : Accueil - Forum - Tutoriels - FAQ - Livres - Blog

    Vous voulez contribuer à la rubrique Oracle ? Contactez la rubrique !

    OCILIB (C Driver for Oracle)

    Librairie C Open Source multi-plateformes pour accéder et manipuler des bases de données Oracle

  19. #19
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Citation Envoyé par Drag Voir le message
    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).

  20. #20
    Membre habitué
    Inscrit en
    Mai 2010
    Messages
    107
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 107
    Points : 132
    Points
    132
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [Oracle] Enlever le case sensitive???
    Par osmoze dans le forum Oracle
    Réponses: 21
    Dernier message: 18/07/2007, 10h40
  2. [DOM] pour ce qui n'est pas dans le body ?
    Par ricault dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 15/06/2007, 16h21
  3. Réponses: 4
    Dernier message: 22/05/2006, 11h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo