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

Débats sur le développement - Le Best Of Discussion :

Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 914
    Points : 51 686
    Points
    51 686
    Billets dans le blog
    6
    Par défaut Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?
    Toutes ces histoire de framework et d'ORM sont les plus belles merdes mercatiques que l'on a fait depuis l'existence de l'informatique. Si vous voulez avoir l'assurance de ne pas finir à temps votre prijet et que ce dernier soit inexploitable lors de la montée en charge, alors allez-y, amusez vous bien avec Hibernate et les frameworks associé comme JPA...

    Voici un extrait de l'article que je suis en train d'écrire sur les dérives de ce genre d'immondices...

    6 – Pourquoi pas un ORM ?

    Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. En sus les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données et qu’il faut à la fois l’un et l’autre si l’on veut être rigoureux. Quant au pilotage du niveau d’isolation des transactions de données, comme les développeurs ne savent même pas de quoi il s’agit, on en constate généralement l’absence !
    Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les développeurs cela leurs permet de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leurs carences.
    Quant à l’argument qui consiste à dire que la maintenabilité d’un code client est bien plus simple qu’un code relationnel, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, laissé les développeurs dans l’ignorance des possibilités de codage dans un SGBDR, pour avoir parfois choisit les mauvais outils (MySQL, SQLite…) on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

    Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…


    A lire sur le sujet :
    http://www.dulcian.com/Articles/Thic...ited_final.htm
    http://thehelsinkideclaration.blogsp...vc-part-2.html

    A +

  2. #2
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 047
    Points : 1 640
    Points
    1 640
    Par défaut
    Reste la question d'un ORM ou non.
    Pour pas mal d'applications où le nombre de requêtes par seconde ne justifie pas d'optimisation, utiliser un orm est une bonne solution.

    @SQLpro : tous les projets ne nécessitent pas d'optimisation à outrance (toutes les applications n'attaquent pas les bases de données sauvagement). Et on peut largement terminer dans les temps avec Hibernate, JPA, ou TopLink.

    Souvent (je te rejoins sur ce point), ces frameworks sont utilisés par défaut parce qu'aucun expert SQL ne traine dans le coin (cependant, l'utilisation d'un ORM requiert malgré tout de bonnes connaissances sur les SGBDR utilisés, et de la norme SQL), et c'est bien dommage. Mais il ne faut pas enterrer les ORM comme tu le fais, car s'ils étaient si catastrophiques que cela (encore faut-il savoir les paramétrer, et cela est un autre problème), ils ne seraient plus beaucoup utilisés et soutenus depuis longtemps (la plupart des projets sont Open Source, donc il n'y a pas de coût de licence exhubérant)...

  3. #3
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    @SQLPro,

    Certains de tes arguments se tiennent et à cause des effets de mode, il y a de mauvaises utilisations des ORM.

    Comme dit Patriarch24, tout le monde n'a pas besoin d'optimisation à outrance et ne dispose pas de DBA compétant sous la main.

    La plus grosse tare pour moi, c'est d'avoir voulu utiliser des bases de données relationnelles avec des langages objets ...

    J'aurai personnellement préféré que se développent les bases de données objets. Seulement, les bases de données relationnelles ont un tel recul historique qu'elles ont eu le temps de devenir de très bons produits ...

    Je ne dis pas qu'il faudrait les laisser tomber pour juste changer de paradigme, je dis juste que cela empêche d'autres alternatives de se développer ... (on ne peut pas reprocher les choix des décideurs vu les qualités des produits) mais le marché est verrouillé et c'est pas demain qu'on aura d'autres solutions ...

    Du coup, on a développé cette solution des ORM a cheval entre les deux, qui n'est pas plus satisfaisante du côté objet qu'elle l'est pour toi du côté base.

    Tu as une vision purement base et comme tous les experts de base de données, j'ai l'impression que tu ne veux utiliser qu'elles pour tout faire (anti-pattern du marteau en or). Si pour des questions de performance, les procédures stockées sont très adaptées, développer des traitements dans une base propriétaire, pour la portabilité, c'est une horreur ! Je ne crois pas qu'il existe de standard en la matière (et c'est malheureux) donc on lie tellement fortement les traitements à la base qu'on devient prisonnier de l'éditeur et le jour où on veut changer, on doit tout réécrire. Et c'est là que tu oublies le principal avantage des ORM (s'il ne devait en rester qu'un), c'est l'indépendance à la base de données pour pouvoir en changer ...
    Certes, je t'accorde que ce n'est pas tous les jours qu'on change mais quand on veut changer, on s'arrache les cheveux (c'est notre cas actuellement)

    Tout ce que j'espère, c'est qu'avec le cloud computing, on remettra en cause la pensée unique du SGBDR (même s'il a des avantages indéniables)

    @+

    Un lien intéressant :
    http://bret.appspot.com/entry/how-friendfeed-uses-mysql

    NB: Concernant ibatis par rapport au code client, je voudrai bien que tu me donnes des sources chiffrées car il n'est pas pour moi un ORM. C'est juste une manière d'externaliser les requêtes SQL du code et de remplir des objets avec les résultats obtenus. Je voudrai bien voir si c'est aussi désastreux que tu le dis car vu qu'on n'a plus l'indépendance à la base, son avantage serait bien mince alors ...

  4. #4
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 397
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 397
    Points : 20 509
    Points
    20 509
    Par défaut
    Citation Envoyé par benwit Voir le message
    La plus grosse tare pour moi, c'est d'avoir voulu utiliser des bases de données relationnelles avec des langages objets ...

    J'aurai personnellement préféré que se développent les bases de données objets. Seulement, les bases de données relationnelles ont un tel recul historique qu'elles ont eu le temps de devenir de très bons produits ...
    euuh j'ai participé à de nombreux projets avec langage objet et SGBDR.
    Dois-je conclure que mes chefs de projets ou DSI précédents étaient tous des idiots alors ?
    Quand aux bases de données objet on en parlait déjà quand j'ai commencé à bosser dans l'informatique il y a plus de 10 ans
    Mais apparemment cela n'a jamais été vraiment un grand succès.

    Citation Envoyé par benwit Voir le message
    Tout ce que j'espère, c'est qu'avec le cloud computing, on remettra en cause la pensée unique du SGBDR (même s'il a des avantages indéniables)
    1- vouloir défendre le cloud computing c'est scier la branche de l'arbre sur laquelle on est assis parce que qui s'occupera de développer et maintenir les applications et infrastructures informatiques distantes ?
    Réponse : les sociétés offshore en asie ou ailleurs.

    2-le cloud-computing c'est une technologie récente rien ne prouve que cela ait du succès techniquement , commercialement et professionellement.
    Les SGBDR cela existe depuis des dizaines d'années et c'est une solution largement éprouvée.

  5. #5
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    Dois-je conclure que mes chefs de projets ou DSI précédents étaient tous des idiots alors ?
    Pourtant j'avais pris soin de bien préciser :
    on ne peut pas reprocher les choix des décideurs
    Je fais une nuance entre théorie et pratique.
    En théorie, je trouve qu'il y a un problème conceptuel à tout faire en objet puis de basculer en relationnel au moment de la persistance. C'est ça que je trouve une tare et c'est une opinion personnel.
    Après, il faut être pragmatique, et en pratique, je comprend bien les choix et c'est pour cela que j'avais apporter une nuance car je ne pense pas que ce sont des idiots. Bien au contraire, ils utilisent des solutions éprouvées.

    Citation Envoyé par Mat.M Voir le message
    Quand aux bases de données objet on en parlait déjà quand j'ai commencé à bosser dans l'informatique il y a plus de 10 ans
    Mais apparemment cela n'a jamais été vraiment un grand succès.
    Et pour cause !
    Peut être effectivement qu'il y a de vrais problèmes et qu'à temps de maturation équivalent (si c'était possible), ça resterait moins bien.
    Mon avis personnel, c'est que les SGBD ont un tel recul, ont une telle maturité qu'il est dur qu'un produit vienne les concurrencer aujourd'hui ...
    Je n'ai pas trop chercher mais il serait intéressant de savoir si ce n'est pas un succès à cause de performance (problème technique ? on en revient à la maturité) ou à cause de marketing (ce n'est pas utilisé donc on ne s'aventure pas dedans ... cercle vicieux)

    Citation Envoyé par Mat.M Voir le message
    le cloud-computing c'est une technologie récente rien ne prouve que cela ait du succès techniquement , commercialement et professionellement.
    Les SGBDR cela existe depuis des dizaines d'années et c'est une solution largement éprouvée.
    Je ne dis pas le contraire.
    Maintenant, croire que c'est LA solution adaptée à tout, je ne le pense pas.

  6. #6
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 397
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 397
    Points : 20 509
    Points
    20 509
    Par défaut
    Ok Benwit je n'avais pas vu la nuance

  7. #7
    Membre expérimenté
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 252
    Points : 1 419
    Points
    1 419
    Par défaut
    Allez, tout le monde switche vers Apache DbUtils !

  8. #8
    Membre chevronné
    Avatar de stailer
    Homme Profil pro
    Architecte technique
    Inscrit en
    Mars 2003
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2003
    Messages : 1 144
    Points : 2 190
    Points
    2 190
    Billets dans le blog
    3
    Par défaut
    Pour répondre à la question posée dans le post, je pense que oui, un ORM mal maitrisé par le développeur peut être dangereux.

    Prenons le cas du pattern Active Record généralement implémenté dans les ORM. Grâce à lui et au Full Lazy Loading il est d'une simplicité enfantine de récupérer des données issues de requêtes "complexes". Par exemple :

    Facture->RecupereClient->RecupereAdresseFacturation

    Ca va marcher mais si on est dans un environnement sensible comportant des centaines de connexions simulantées, à quel prix ?

    Une requête INNER JOIN placé dans le modèle (ou l'appel à une proc stockée) remplacera avantageusement ce processus.

    A contrario , ça ne veut pas dire non plus qu'il faut faire des requêtes partout . Bref, encore une fois : c'est à la compétence du programmeur à mon avis

  9. #9
    BsT
    BsT est déconnecté
    Membre régulier
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    72
    Détails du profil
    Informations personnelles :
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Juillet 2004
    Messages : 72
    Points : 83
    Points
    83
    Par défaut
    @Stailer

    C'est prévu (du moins pour Hibernate)

    http://bmarchesson.developpez.com/tu...te/chargement/

    @Benwit + 1

    On fait tourner le même progiciel sur 4 bases différentes (Mysql, Oracle, SqlServer et RDB !), et oui certains de nos clients ne peuvent se payer une licence Oracle....

  10. #10
    Membre éclairé

    Inscrit en
    Février 2007
    Messages
    122
    Détails du profil
    Informations forums :
    Inscription : Février 2007
    Messages : 122
    Points : 659
    Points
    659
    Par défaut
    Je suis relativement d'accord sur les dangers des frameworks ORM, comme ça a été dit ça peut être un bon outil mais c'est un peu comme tout c'est à la compétence du développeur.
    On peut aussi pondre des trucs infâmes en SQL et procédures stockées.
    Et personnellement j'ai vu plus de code infâme en SQL qu'avec Hibernate.

    Maintenant niveau perf, j'ai récemment fait des benchmarks pour une appli nécessitant des perfs, et si le code est bien fait, Hibernate va plus vite en lecture (en partie grâce aux caches) mais est plus lent en écriture. Ce qui e a entraine le choix d'Hibernate pour les accès en lecture, et de JDBC pour tout ce qui va remplir la base.

    Après avant de rentrer dans le lard du truc et en traitant haut et fort le concept de "merde" je pense qu'un peu d'auto critique ne serais pas de trop.

    Je suis entièrement d'accord sur le principe, avec les framework orm les développeurs oublient le fonctionnement basique du SGBDR et ne savent plus faire de SQL pur, néanmoins faut aussi reconnaître que d'un point de vue productivité c'est même pas comparable.

    Pour ce qui est de la finalisation des projets, j'ai bossé sur des projets industriels qui tournent avec Hibernate et marchent très bien.

    Donc même si je suis d'accord avec toi sur une partie des arguments, je pense qu'il faut aussi savoir évoluer.
    Ton raisonnement est typique des pro C qui descendent les langages modernes en disant que c'est de la merde. Et je dis ça alors que le C et le C++ font partie de mes langages favoris.

    L'incompétence du développeur ne rend pas "nul" et "merdique" un outil. Honnètement moi les développeurs qui se content d'être des utilisateurs simple, et ne cherchent pas à savoir ce qu'il y a derrière leurs fonctions "magique" je les plein plus qu'autre chose.

    Ensuite si t'as un super db admin il fera tout bien comme il faut le SQL. Si t'as un développeur qu'aime pas le SQL il va bacler le truc et t'auras tout gagner ...
    Mais je crois surtout qu'aujourd'hui on s'en fou un peu de perdre un peu de perf, car la performance coûte moins cher que la compétence.

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    Février 2007
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 49
    Points : 91
    Points
    91
    Par défaut
    Je ne n'utilise pas encore d'ORM mais je comptait en tester pour utilisation future (mon avis n'est donc absolument "pas éclairé"). Pourquoi ?
    D'un point de vue développeur je vois a priori comme avantages :
    - gains important de temps de développement
    - lazy-loading et cache des données
    - indépendance vis à vis de la base de données

    Face à ces avantages, la perte de performances (si elle n'est pas trop importante) ne me dérange pas : on est pas tous sur des applications avec des centaines de connections simultanées et des To de données...

  12. #12
    Invité
    Invité(e)
    Par défaut Pas d'accord
    @SQLPro:
    Assez peu d'accord.
    Pour moi on se rapproche analogiquement de l'ancestral débat quand on est passé des langages assembleurs aux langages compilés de plus haut niveau, comme le C par exemple.
    Les gens de ton espèce disaient alors que c'était une abbération :
    -plus de code dans certain cas qu'une bonne optimisation de l'utlisation des registres
    -moins performant
    -surcharge de processeurs et mémoire mal gérée
    -etc...

    Franchement, qualifier aujourd'hui les ORM qui deviennent bien aboutis d'"immondice", pour moi c'est aller trop loin et faire soit preuve d'une fermeture d'esprit assez hallucinante, soit simplement vouloir faire du sensationnalisme avec des gros titres et arguments tape-à-l'oeil voulant ne laisser personne indifférent.

    Dans bien des projets les ORM simplifient la vie des développeurs, qui sont loin d'être tous expert en SQL et administration de base de données (il faut savoir que quelqu'un qui a une vraie double compétence base de donnés / développement est un profil très rare, côté très cher, souvent trop pour les entreprises).
    Les ORM permettent de livrer des solutions aux performances acceptables dans la plupart des cas (même si on est d'accord qu'on égalera jamais celle d'une procédure stockée sur le serveur SQL), avec un maximum de simplicité et de souplesse quant aux modifications et la maintenance évolutive grace à la couche de liant objet entité/objet donné, et la génération du code nécessaire sans devoir passer par sa ré-écriture complète.

    Bref, dans bien des cas, non seulement l'ORM me semble une solution acceptable, mais aussi intelligente.

  13. #13
    Membre du Club
    Inscrit en
    Novembre 2005
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 50
    Points : 64
    Points
    64
    Par défaut
    Je vais mettre mon petit grain de sel dans cette discussion.

    Ayant été comme certains développeurs C par le passé, j'ai une tendance à rechercher la performance, cela n'empêche qu'Hibernate est un framework dont j'apprécie certaines vertus (cache session, cache de second niveau, etc.).

    Etant utilisateur d'Hibernate, le gain en terme de productivité est indéniable lorsqu'on maîtrise le framework. Pour un rookie qui n'a aucune conscience de ce qu'il se passe dans la boite noire c'est effectivement très risqué de lui laisser le framework entre les mains.

    Attention de ne pas voir en l'ORM un outil miracle. Il est juste adapté à certains besoins.

  14. #14
    Expert éminent
    Avatar de neo.51
    Profil pro
    Inscrit en
    Avril 2002
    Messages
    2 663
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations forums :
    Inscription : Avril 2002
    Messages : 2 663
    Points : 6 418
    Points
    6 418
    Par défaut
    En voilà un débat intéressant !!!

    Je pense que le gros soucis des ORM c'est qu'on voit des accroches commerciales du genre :

    Ne vous occupez plus de la base de données grâce à XXX
    et là forcément c'est le drame

    Après de là à dire que le choix d'un ORM est toujours un mauvais choix il y a un pas que je ne franchirais pas. Chaque projet informatique est différent. Je suis pas fan des ORM mais bien forcé de constaté que le gain en temps de développement est quand même assez significatif. En admettant que les développeurs n'utilisent pas l'ORM comme une boite noire magique l'utilisation de tels outils est quand même une avancée intéressante.

    C'est au DSI de faire les bons choix. Un ORM est un outil parmi d'autre où l'on se doit d'étudier le pour et le contre avant de l'utiliser dans un projet. Mais c'est pareil pour le langage utilisé et bien d'autres composantes.

  15. #15
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Le plus dur, c'est de trouver un compromis entre POO et SGBDR. Une procédure stockée bien écrite peu remplacer des centaines de lignes de code objet imbuvable et peu performant. S'il faut venir sans cesse avec l'argument de la portabilité, c'est au prix de la performance.

    Cependant, être indépendant d'un SGBDR, c'est être dépendant d'un ORM .

  16. #16
    Membre régulier
    Profil pro
    Inscrit en
    Février 2007
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 49
    Points : 91
    Points
    91
    Par défaut
    Citation Envoyé par chaplin Voir le message
    Cependant, être indépendant d'un SGBDR, c'est être dépendant d'un ORM .
    C'est vrai, mais l'ORM est (en tout cas pour moi) un choix uniquement interne, alors que différent SGBDR peuvent nous être imposés pour le même produit.

  17. #17
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 914
    Points : 51 686
    Points
    51 686
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par benwit Voir le message
    Si pour des questions de performance, les procédures stockées sont très adaptées, développer des traitements dans une base propriétaire, pour la portabilité, c'est une horreur ! Je ne crois pas qu'il existe de standard en la matière (et c'est malheureux) donc on lie tellement fortement les traitements à la base qu'on devient prisonnier de l'éditeur et le jour où on veut changer, on doit tout réécrire.
    Si le SQL est aussi normé sur les aspect procédures stockée (PSM : Persistant Stored Module). Notamment tout ce qui est gestion des variables, des exceptions, des curseurs....
    Néanmoins, beaucoup d'éditeurs se sont écartés de la norme (Oracle en particulier, SQL Server aussi).
    Mais c'est le seul moyen d'avoir des objets qui renvoient les mêmes données. Regardez le test que j'ai fait ici : http://sqlpro.developpez.com/cours/s...age=partie1#L3
    Une même requête SQL toute simple donne différents résultats en fonction des différents SGBDR ! Mais ces résultats peuvent devenir identique en masquant les différentes écritures de cette même requête au sein d'une procédure. Et c'est le seul moyen d'être compatible entre différents SGBDR !

    Donc contrairement à cette affirmation :
    Citation Envoyé par benwit Voir le message
    Et c'est là que tu oublies le principal avantage des ORM (s'il ne devait en rester qu'un), c'est l'indépendance à la base de données pour pouvoir en changer ...
    L'ORM n'apporte pas actuellement cet avantage. Il ne sert pratiquement à rien !

    Sachez cependant que ce que j'ai dit est un extrait d'un article plus complet à paraître dans la monde informatique, ou j'exprime ce vœux :
    Cependant, je crois fermement en l’avenir de l’ORM. Pas de ceux qui existent de nos jours. Mais de celui qui sera capable de titrer partie des possibilités des SGBDR. Je rêve d’un ORM capable de créer automatiquement, les vues correspondant aux objets modélisés, les procédures stockées de synthèse pour la mise à jour globale des tables relatives au mapping de l’objet au modèle relationnel, et finalement d’implémenter les déclencheurs INSTEAD OF adéquats pour assurer la correspondance entre vues et procédures … Ce n’est certes pas pour bientôt, mais c’est sans aucun doute vers cet avenir meilleur qu’il faut tendre. En attendant, c’est encore à la main que les choses se passent.
    A +

  18. #18
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 914
    Points : 51 686
    Points
    51 686
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Plageman Voir le message
    - gains important de temps de développement
    TOTALEMENT faux ! Regardez les métriques de DULCIAN !
    http://www.dulcian.com/Articles/Thic...ited_final.htm

    Citation Envoyé par Plageman Voir le message
    - lazy-loading et cache des données
    Ce que font tous les SGBDR C/S et généralement en mieux...

    Citation Envoyé par Plageman Voir le message
    - indépendance vis à vis de la base de données
    TOTALEMENT faux ! Regardez mon post précédent...

    A +

  19. #19
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2008
    Messages
    168
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Février 2008
    Messages : 168
    Points : 478
    Points
    478
    Par défaut
    Intéressante discussion.

    Ayant pas mal travaillé sur WebObjects (EOF) et sur du J2EE plus tard, j'ai constaté par moi-même que les ORM ne sont pas très performant, surtout si on a des novices dans l'équipe (C'est facile à programmer, mais après, bonjours les dégâts). Par exemple tester l’existence d’une relation entre deux objets, c’est toujours plus simple de le faire avec une petite requête SQL, que de passer par l’ORM.

    De plus, il vaut mieux faire le schéma de la base de données en fonction du schéma décrit dans l’ORM que l’inverse. Ce qui est gênant si l’on par d’une base existante.

    La meilleure solution c’est quand même l'utilisation de générateurs de code, qui fait le mapping à la main. Cela permet d'optimiser ses requêtes (syntaxe SQL), notamment quand plusieurs tables sont en jeux.
    Quand on me dit que c'est plus simple de changer de bases de données avec un ORM, je crois que c'est tout simplement un argument marketing à la c.

  20. #20
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    TOTALEMENT faux ! Regardez les métriques de DULCIAN !
    http://www.dulcian.com/Articles/Thic...ited_final.htm
    Je sais pas.

    J'ai vu nulle part dans vos dires ou ceux que vous citez en référence tout ce qui concerne l'évolution et maintenance après livraison.
    Or, n'importe qui ayant un minimum d'expérience en projets "réels" (par opposition au monde universitaire et recherche) informatique sait que l'évolution et la maintenance font une grosse part du temps alloué au développement.
    Les demandes d'évolutions diverses du logiciel, l'évolution indépendante des plateformes sur lequel il est utilisé, etc... , forment une grosse partie des couts de ces projets.

    Or en ce sens, l'ORM me semble apporter un gain non négligeable en temps (et donc argent) dépensé à l'occasion de cette maintenance évolutive ; contrairement au SQL brut et dur qu'il faut ré-écrire parfois presque entièrement pour peu que le schéma de la base de donnée ait été modifié par une autre équipe.
    Dans le cas de l'utilisation d'un ORM, c'est le plus souvent juste une modification du mappage des objets entités sur les tables.

    De plus, de nouveau par expérience, même si les ORM ne sont aujourd'hui pas complets, 98% des requetes SQL écrites au court un projet "réel" sont des simples Select, Update, Delete, Insert.
    Alors de là à aller reprocher le fait qu'un ORM n'implémente un trigger INSTEAD OF, c'est presque de la "branlette intellectuelle" comme on le dit souvent ; ce qu'on essaye d'éviter un maximum et qu'on laisse souvent aux gens qui en ont le temps et pas de contraintes de délais et couts

Discussions similaires

  1. Les IDE sont-ils dangereux pour les développeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 85
    Dernier message: 13/05/2014, 11h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 19h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 08h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 08h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 23/11/2008, 23h13

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