Bonjour,
Si vous maitrisez un ORM, y a-t-il des cas où vous préférez ne pas utiliser d'ORM, et donc de développer en SQL je pense ?
Merci,
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
Discussion :
Si vous maitrisez un ORM, y a-t-il des cas où vous préférez ne pas utiliser d'ORM ?
Bonjour,
Si vous maitrisez un ORM, y a-t-il des cas où vous préférez ne pas utiliser d'ORM, et donc de développer en SQL je pense ?
Merci,
Oui.
Je préfère nettement maîtriser la partie SQL de mes programmes et je fais l'architecture de la BDD avant le programme ; pas question que ce soit l'ORM qui crée les tables !
En plus les ORM semblent avoir la mauvaise manie de vouloir réinventer un pseudo SQL pour faire les requêtes par morceaux et il est bien plus rapide de faire la requête en SQL natif et demander à l'outil du programme qui s'interface avec le SGBD (même si c'est un ORM) de lancer les requêtes écrites en SQL natif.
Lisez ceci : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
Vous serez convaincu que le ORM constituent une véritable plaie en matière de performance et à long terme s’avèrent plus couteux à tous niveau (temps de codage, maintenance, performances...) C'est pourquoi on les qualifient de guerre du Vietnam !
En sus vous pouvez avoir une bonne indication des performances catastrophiques d'un ORM an lisant cet article : http://www.ormbattle.net/
Bref, un ORM comme nHibernate est 24 fois plus lent pour un simple INSERT que le SQL !!!
A +
et oui, c'est vraiment catastrophique.
Il y a 20 ans on programmait avec de l'IMS et du PL1 et ca dépotait severe
Apres on a fait du Cobol avec du DB2 et du relationnel, c'etait plus lent mais ca allait encore.
Apres on a fait du java et c'etait lent.
Maintenant on a ajouté des ORMs et là sur des machines surpuissantes, j'ai des batchs qui tournent aux memes vitesses qu'il y a 20 ans sur des machines équivalentes à des Pentium 75 Mhz avec 8Mo de RAM.
Il y a 4 ou 5 ans, j'avais un collegue qui vient tout fier me dire j'ai un batch qui insere 160000 lignes de données et qui fait des calculs de cumul de CA en 10 minutes...
Super j'ai pris le meme fichier, j'ai fait un batch Cobol, ca faisait la meme chose en 38 secondes chrono...
Vive le progres !
En même temps les ORM n'ont jamais été fait pour faire des pgm batch.
Ils ont leur utilité quand on traite 1 élément (ligne), en facilité de dev.
Par contre au delà de ça je préfère utiliser du sql.
Et voilà ! Ça ne sert qu'à ça ! et encore, comme j'ai dit plus haut, c'est plus rapide d'écrire une requête SQL qu'avec le pseudo SQL saucissonné des ORM !Envoyé par punkoff
Et encore, sur un applicatif tout le SQL devrait être dans des vues et procédures stockées, l'application n'appelant que ces dernières en envoyant simplement des paramètres.
Ne vous en déplaise le gain de temps pour gérer des CRUD basic n'est pas à négliger.
Vu que vous n'avez strictement aucune requête à écrire, pas de synchronisation d'objet pour changer de couche, etc.
Je veux bien qu'on tappe dessus, mais il faut quand même rester objectif sur les possibilités qu'offre un ORM.
Un ORM n'est qu'un outil : il ne faut pas le rendre responsable des manquements de ceux qui l'utilisent à tort et à travers.
Toutes les applications ne bénéficient pas d'un ORM (et même dans une application toutes les fonctionnalités) : les détracteurs ont tendance à prendre des exemples où l'intérêt d'utiliser un ORM est plus que discutable.
Et s'il y a bien un manquement chez les vendeurs d'ORM, c'est de n'offrir aucune méthodologie qui permette de distinguer clairement les conditions "GO - NO GO".
En même temps c'est un forum SGBD ...
C'est comme proposer un language de script sur un forum C++.
Je dirais que peut importe la technologie, ce qui compte c'est la personne qui l'utilise.
L'ORM comme le fait de développer énormement dans le code vient des lacunes des bases de données pour gérer les développements quoiqu'en disent les évangélistes SGBD.
Et comme les SGBD ne sont pas des plateformes de développement acceptables, on a tendance à ne les utiliser que pour le stockage. Parce que pour des consérations de gestion de projet, ça enlève une techno finalement peut compatible avec les autres (quand vous débuggez un code en Java et qu'il apelle une procédure stockée, vous ne pouvez pas entrer dans cette procédure) et surtout qu'en général personne n'a les deux compétences (SQL + le language de dev).
J'ai vu un exemple où la majorité du code métier était en SQL et ça n'évite en rien les dérives.
J'ai vécu quelques mésaventures avec Hibernate utilisé par le framework Seam l'an dernier.
Un exemple de ce que je disais ici plus haut : c'est plus facile en SQL pur ! Vous pouvez lire toute la discussion si ça vous intéresse pour comprendre la galère ce cette usine à gaz !
Un autre exemple sur la soi-disant facilité apportée par l'automatisation du mapping ! Et dans la même discussion, encore un exemple concret d'une requête un peu complexe impossible à faire avec Hibernate et relativement facile à faire en SQL pur.
Je ne retrouve pas rapidement le lien mais il me semble aussi avoir remarqué que Hibernate interrogeait des tables de la BDD dont je n'avais pas besoin. Autrement dit, il complique inutilement les requêtes pour traficoter les données comme bon lui semble !
Bref, après quelques mois de galère, j'ai redéveloppé entièrement le projet en PHP avec Zend Framework pendant ma semaine de vacances de Noël et avec des modèles plus simples et des requêtes en SQL natif.
Pour ne pas parler que de mes mésaventures avec Hibernate, j'ai aussi vu récemment plusieurs messages de personnes qui avaient des problèmes pour faire fonctionner, ou simplement écrire, des requêtes relativement simples avec Doctrine.
Non vraiment, jusqu'ici, je n'ai vraiment pas vu grand chose de positif aux ORM que j'ai rencontrés !
C'est pour ce genre de problème que l'on met en place un projet avec ... un architecte java.
Je ne dirais pas le contraire qu'un orm te bride d'une certaine manière sur les possibilités de modélisations.
Après selon le projet, ce bridage est plus ou moins critique, et le contournement peut ou non être acceptable.
Faut pas oublier quand même que tu peux mapper des vues ... déporter les traitements de type batch / complexe dans des procStock, etc...
Mixer les deux approches n'est pas si débile en soit il faut juste avoir une équipe qui tienne la route => laissez les traitements simple à l'orm, ensuite déporter les requêtes / objet complexe dans des vues et si vraiment nécessaire faire des traitements via proc-stock / pgm batch appelé via proc-stock.
Fin bref, je suis assez d'accord sur l'interprétation de JeitEmgie et un peu sur celle de Jetser.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager