Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Êtes-vous pour ou contre les ORM ?
Un blogueur invite à tenir le bâton par le milieu

Le , par tarikbenmerar

118PARTAGES

6  0 
S'il y a bien une constante dans la nature humaine, c'est celle qui rend tellement rare qu'un choix ou un avis particulier fasse partout l'unanimité.
Le monde de l'informatique et du développement ne dérogent pas à cette règle. C'est même un domaine où les guéguerres idéologiques peuvent être les plus enflammées et les opinions des plus tranchées.

Des décennies durant, de vifs débats reviennent encore et encore dans les communautés de développement : Big Endian vs Little Endian, EMACS vs Vi(m) ou Java vs .NET, pour ne citer que les plus notables.

Mais au-delà du débat, constructif ou répétitif, il est incontestable que le vrai gagnant est celui qui arrive à synthétiser les qualités et les faiblesses de chaque opinion dans un contexte précis. Qui arrive à en extraire l'essence pour adapter son choix au besoin particulier de chacun.

C'est avec cette philosophie qu'aborde Andy Boothe le débat sur les ORM dans un billet de son blog SIGPWNED.

L'ORM (mapping objet-relationnel) est une technique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé.



Andy Boothe commence par étayer les avis de chacun, pour nous laisser les meilleures pratiques pour la fin. Entre les modeleurs (les pro-ORM) et les persistants (les anti-ORM), Andy préconise les habitudes suivantes :

  • Utilisez des objets modèles les plus simples possible, lors de l'utilisation de l'ORM. Il faut être vigilant de ne pas sur-simplifier et s'assurer que les modèles reflètent tout simplement l'ancien modèle de données. Autrement on fera face à un effort non négligeable avec l'ORM pour s'assurer que la persistance marche comme prévu pour ne pas chercher des méthodes et des propriétés manquantes.
  • Si vous n'utilisez pas l'ORM, vous devez probablement définir des DAO (Data Access Objects) ou des méthodes de requête et de persistance, pour éviter un couplage fort entre la couche modèle et la couche persistance. Sinon, vous vous retrouverez avec du SQL dans les objets modèles et avec une dépendance forcée.
  • Si vous savez que les schémas d'accès aux données seront simples, mais vous ne les cernez pas entièrement, vous devriez songer à utiliser un ORM. Même si les ORM peuvent rendre difficile de créer et de déboguer les requêtes complexes, ils s'avèrent efficaces et permettent de gagner beaucoup de temps pour des requêtes simples.
  • Si vous savez que les schémas d'accès aux données seront complexes ou que divers mécanismes spécifiques à un SGBD particulier seront utilisés, il est préférable d'éviter les ORM. Même si certains ORM, tels que Hibernate, permettent un accès facile à la connexion sous-jacente, les avantages seront perdus si vous vous retrouvez à utiliser beaucoup de SQL personnalisé.
  • Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.


Et vous ?

Êtes-vous pour ou contre les ORM ?
Pouvez-vous justifier votre choix ?
Votre choix s'adapte-t-il au type de développement que vous faites ?

Source : Billet de blog de sigpwned

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 18/08/2012 à 12:21
Citation Envoyé par erwanlb Voir le message
(bien au contraire, donner les moyens à des petits rigolos de créer des crises boursières, est ce bien sérieux ? )
Ça c'est un autre débat (est-ce que les métiers vraiment utiles à la société sont récompensés à leur juste valeur ?) dans lequel je n'ai pas vraiment envie de rentrer.

L'idée importante, c'est que c'est le genre de système qui doit être performant et tenir la charge, mais merci de déformer mes propos...

Citation Envoyé par erwanlb Voir le message
2 boites wahou....quel vécu
Et bien oui... je ne suis pas du genre à rentrer dans une boite pour quelques mois, y laisser ma petite "trace" personnelle (généralement sous la forme d'un étron nauséabond), toucher mon gros chèque, et me barrer avant que tout n'explose à la figure...

Quand je rentre dans une boite, c'est généralement dans le but de travailler sur des projets qui s'inscrivent sur la durée, d'apporter des solutions et de faire un suivi des évolutions.

Généralement ça marche plutôt bien, jusqu'au jour où la boite demande que l'on fasse des "compromis". À partir du moment où l'ensemble de ces compromis représentent plus de contraintes que de chercher un nouveau "challenge", cela marque souvent le début de la fin pour la collaboration professionnelle.

La durée du contrat dépend donc souvent du délai au bout duquel la phase de "compromis" apparait, et n'a donc aucun rapport avec l'appréciation de l'employeur (même si curieusement, cette appréciation diminue rapidement peu après le refus dudit "compromis".

Tout ça pour dire (ne t'en déplaise, j'aime bien les explications détaillées et argumentées) que c'est pas facile de cumuler les boites quand on reste 4 ans dans la même entreprise. Je n'ai pas encore le don d'ubiquité...

Au final, il s'agit vraisemblablement de savoir dans quel camp on se trouve:
- les gens qui essayent de faire leur boulot correctement dans le but de trouver de réelles solutions
- les gens qui veulent exploiter le système: donner l'illusion d'être de grands professionnels mais, faute d'arguments convaincants, en viennent à dénigrer les autres et à déformer leurs propos
- les "petits rigolos" à qui la société a donné les moyens de "créer des crises boursières" (ou toute autre forme de pouvoir)

Et d'une certaine façon, même si on parait s'éloigner du sujet, c'est au contraire pour mieux rentrer dedans: s'interroger sur le développement informatique au sens large et se demander "quels outils (ORM, RAD ou autres) utilisent les gens du premier et du deuxième camp ?"

Citation Envoyé par erwanlb Voir le message
Pour le reste, tu pars dans un blabla qui s'éloigne un peu trop du sujet dans le sens ou à part montrer à quel point tu prends les gens de haut...
Pardon ?

Que je sache, ce n'est pas moi qui ait balancé des énormités du genre "Vu les arguments utilisés on en est au stade d'un débat genre Win/Linux, iOS/Android...." ou bien encore "Est ce que ceux qui sont contre les ORM les connaisse et les ont utilisé ?".

Mais je comprends parfaitement, c'est un comportement que j'ai rencontré de nombreuses fois sur les forums:
- on va sur un forum public
- on part du principe qu'on est un dieu dans son domaine (ex: les ORM)
- on les propos d'un type qui montre les avantages d'une approche differente
- on sous-entend que c'est un abruti et qu'il n'y connait rien sans pour autant être en mesure d'apporter de contre-argument (à part un vague "si les ORM existent c'est qu'ils sont utiles")

Et je ne suis pas le seul à qui tu t'en prennes : quand imikado a tenté de fournir des arguments, benchmark à l'appui, tu as tout simplement dénigré ses commentaires.

Donc non, je ne pense pas avoir la science infuse, mais quand un individu lance des attaques personnelles dans le seul but de se mousser, il a intérêt à être en mesure de présenter des contre-arguments pertinents plutôt que de se contenter de basses attaques personnelles.

Maintenant, juste pour information, mes remarques à ton égard sont encore relativement "gentilles" et je conseille très fortement d'arrêter tout de suite tes commentaires stériles et sans fondement ainsi que toute forme d'attaque personnelle envers tout personne fréquentant ce forum.

Jusqu'ici on en est encore au stade de la discussion, mais la prochaine étape pour toi c'est la case "modération" (et comme tu peux le constater, tout le détail se trouve déjà dans ce poste, donc ça risque de ne pas prendre très longtemps). À toi de voir...

Citation Envoyé par erwanlb Voir le message
A défaut d'avoir un rasoir tu l'auras été
Tiens, une attaque personnelle...

C'est censé être un calembour ? Un jeu de mots particulièrement recherché ? Cela ressemble plus à une reflexion de classe de maternelle...

Maintenant si ma prose t'ennuie (bien d'autres certaines personnes semblent vraisemblablement l'apprécier), personne ne t'a demandé de rester...

Citation Envoyé par erwanlb Voir le message
A la semaine prochaine pour notre prochaine consultation...
Tiens, encore une attaque personnelle puérile ?
14  3 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 15/08/2012 à 13:05
Je ne suis pas forcément pour ou contre.
L'article cite assez bien les avantages et inconvénients de l'utilisation d'un ORM.

Contre :
  • Pour ma part ayant déjà utilisé Doctrine, je trouve qu'on est techniquement limité pour faire des requêtes complexes, il faut alors passer par le DQL (requête doctrine, équivalent de HQL pour Hibernate), et là encore je ne suis pas sur d'arriver à ce que je veux.
  • Bien sur il y a cette grosse couche d'abstraction qui peut nuire aux performances... et d'après ce que j'ai compris un ORM peut effectuer plus de requête que nécessaire parfois.
  • Bien maitriser un ORM demande beaucoup de temps de formation (les entités, les annotations, les contraintes...).


Pour :
  • Dans l'ensemble, utiliser des objets et leurs méthodes facilite le développement, on évite de passer par des méthodes contenant de longues chaines de requêtes SQL.
  • Les données sont persistants.
  • Notre application devient multi-BDD (ex: fonctionne aussi bien sous MySQL que sous PostgreSQL ou autre...)
9  0 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 18/08/2012 à 6:14
Citation Envoyé par imikado Voir le message
Je préconise l'écriture des requêtes en SQL dans les classes modèles
Je préconise plutôt l'écriture de procédures stockées pour des traitements un peu complexes et nécessitant plusieurs requêtes.

L'avantage des procédures stockées, c'est que:
- on peut définir une suite de requêtes et faire des traitements assez complexes
- on peut gérer ses transactions dans la procédure

Et pour reprendre tes arguments:
- les requêtes sont centralisées (mais en plus on peut les modifier sans avoir à tout recompiler et re-déployer)
- on identifie très facilement les paramètres
- on gagne en transparence et en performances (tout est exécuté directement sur le serveur, pas besoin d'échanger de données intermédiaires entre l'appli et le SGBD)

L'inconvénient, c'est que si on a beaucoup de fonctionnalités nécessitant seulement une requête SQL, on se retrouve avec beaucoup de procédures à gérer...

Mais bon, si toutes les fonctionnalités peut être implémentées en une seule requête à chaque fois, c'est qu'on ne travaille pas sur un système vraiment complexe, et dans ce cas ça n'a pas grande importance si on utilise des requêtes séparées, un ORM ou autre chose...

Citation Envoyé par rawsrc Voir le message
@pcaboche
joli post, ça sent sacrément le vécu tout ça, dis donc...
1 stage et 1 entreprise (mon entreprise actuelle. L'entreprise précédente avait d'autres défauts au moins aussi irritants mais de nature différente).

Citation Envoyé par rawsrc Voir le message

Je ne vais pas me la jouer Mireille Dumas, mais tu devrais consulter pour te faire du bien.
J'ai consulté de par le passé.

Il en résulte que:
- ça ne sert à rien de garder ses problèmes pour soi. Mettre ses problèmes sur le papier est libératoire et constitue un début de thérapie
- le fait de partager ses pensées et expérience permet de voir que l'on n'est pas seul à rencontrer ce problème
- voir des gens partager votre opinion est rassurant, voire glorifiant
- si d'autres personnes trouvent la discussion utile, tout le monde en ressort gagnant

Et puis j'aime pas Mireille Dumas à cause des conneries qu'elle a pu raconter sur les jeux de rôles au milieu des années 90.

Mireille, si tu nous lis (on ne sais jamais, peut-être que tu prépares à nouveau à cracher ton venin, stigmatiser et proférer des propos diffamatoires envers un groupe d'individus choisi au hasard), sache qu'une majorité d'anciens rôlistes sont des personnes parfaitement saines d'esprit et certains occupent aujourd'hui des postes à responsabilités. Les quelques cas qui ont mal tourné avaient vraisemblablement des problèmes d'ordre psychologiques, éventuellement entretenus par le ramassis de conneries dont la télévision nous abreuve quotidiennement.

Mais là je crois qu'on s'éloigne légèrement du sujet original, non ?
9  2 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 30/11/2012 à 16:17
J'appelle les ORM des Objets Réellement Merdiques !

J'ai eu une très mauvaise expérience avec Hibernate qui a valu l'ouverture de quelques discussions de ma part sur DVP.
Très pratique pour du CRUD simple mais insupportable sur des requêtes un tantinet complexes. Une requête multi-jointures que j'arrivais à écrire en moins d'un quart d'heure en SQL, je n'ai tout simplement jamais réussi à obtenir le même résultat en HQL !

Avec le Zend Framework, je me passe facilement de la syntaxe de Zend_Db pour écrire rapidement et simplement mes requêtes en SQL pur et les soumettre ainsi. C'est d'ailleurs la méthode que j'avais fini par employer avec Hibernate.

J'ai jeté un œil à Doctrine et ça m'a donné l'impression qu'il a les mêmes défauts que Hibernate. Quand je me lancerai sur un projet avec le Zend Framework 2, ma doctrine sera fort probablement de ne pas l'utiliser !

Pour celui qui maîtrise un minimum le SQL, devoir apprendre un dialecte de SQL dans un ORM, c'est du temps perdu. Quand on écrit ses requêtes, on les maîtrise. Avec un ORM, on ne sait pas ce qu'il produit comme requêtes. Et quand on cherche à le savoir, on se dit qu'on aurait mieux fait de rester dans l'ignorance tellement ça fait peur !

Au vu de l'ensemble de la discussion, il semble que la plupart des intervenants soient au moins circonspects quant à l'utilisation des ORM, voire farouchement opposés, comme moi. Et vous avez de la chance que SQLPro ne soit pas passé par là !
7  0 
Avatar de Stopher
Membre averti https://www.developpez.com
Le 15/08/2012 à 13:28
Pour et contre,

pour moi il est essentiel de maitriser ce qui se passe lorsque l'on code.

Il convient d'apprendre à utiliser les bases de données sans ORM, et lorsque l'on a le temps/l'occasion/la contrainte/la volonté d'utiliser/d'apprendre à utiliser un ORM.

L'utilisation d'un ORM apporte aussi de nouvelles contraintes technique qui ajoute encore un "pseudo langage" à apprendre qui va différer d'une techno à une autre ...

N'étant personnellement pas lié à un langage particulier je me méfie comme la peste des couches d'abstraction qui permettent "d'arriver plus vite" à ses fins. de plus si le code se veut maintenable, la lib ORM doit être maitrisée par ses mainteneurs .. bref ...

ça peut vous simplifier la vie, comme la rendre plus compliquée ... à utiliser en connaissance de cause

Ch.
7  1 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 15/08/2012 à 15:37
Bonjour,
Citation Envoyé par erwanlb Voir le message
Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...
Faut pas pousser non plus : comme si gérer une connexion à une BDD filait obligatoirement des maux de têtes et concernant le langage SQL, il faut le mettre en parallèle avec l'apprentissage de ceux embarqués par les ORM le HQL et DQL (pour les plus connus). Pour moi c'est kif-kif.

Le seul hic avec l'abus des ORM c'est quand tu tombes sur un environnement qui t'oblige pour des raisons de sécurité, de performance... à ne passer que par des procédures stockées et là comme je l'ai vu récemment l'abus d'ORM nuit gravement à la productivité.

Alors sans être expert en SQL, il faut quand même avoir de bonnes notions en bases de données et en langage SQL, le reste c'est un plus mais à consommer avec modération.
6  0 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 15/08/2012 à 18:17
Citation Envoyé par tarikbenmerar Voir le message
  • Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.
Rare ? Au contraire, c'est super répandu !

J'irais même plus loin: c'est quoi l'intérêt de développer un Système d'Information incapable de tenir la charge ?

Là où je suis d'accord, c'est qu'un ORM dans ce cas, c'est pas la joie. Typiquement:
- ça créé une transaction (par ce qu'on en a besoin pour assurer l'intégrité des données)
- ça fait plein de petites requêtes qui, cumulées, utilisent pas mal de ressources
- pendant tout le temps où la transaction est restée ouverte, d'autres applications ont eu le temps de faire des timeouts...

À ce niveau là, je préfère une bonne procédure stockée qui fait des bons gros traitements par lots, et de manière efficace.

C'est vrai que la POO c'est rassurant parce qu'on comprend les interactions entre objets, et que l'algèbre relationnelle ça fait peur à pas mal de gens. C'est vrai que certaines procédures stockées font mal à la tête quand on doit les relire (surtout si elles sont mal indentées, c'est une horreur !) mais souvent, quand on voit tout ce qu'il faut écrire en POO pour arriver au même résultat (mais en moins performant), c'est même pas la peine !

Un autre avantage des procédures stockées, c'est que si on se rend compte d'un problème, on a juste à modifier la procédure pour que les changements prennent immédiatement effet, pas besoin de tout recompiler et redéployer...

J'ai un collègue développeur qui m'a raconté qu'il ne s'était jamais intéressé au SQL... jusqu'à ce qu'il me rencontre et qu'il voie ce qu'il est possible de faire avec du SQL. Depuis il me pose plein de questions.

À la base, je ne suis pas partisan d'une solution plutôt qu'une autre. Mais quand on a des deadlines parfois assez serrées, on va vers la solution qui permet de réduire les temps de développement. Et quand à cela s'ajoutent des contraintes de performance...
7  1 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 17/08/2012 à 19:00
Citation Envoyé par erwanlb Voir le message
Je dis pas compliqué parce que j'ai pas eut l'occasion d'être sur des projets où la vitesse est requise...
Justement, si tu n'as jamais eu l'occasion de travailler sur des projets un tant soit peu sérieux (ex: des applications connectées aux marchés boursiers avec des transactions dans tous les sens) pourquoi tu te permets de donner ton avis ?

Et comme si cela ne suffisait pas, tu as l'outrecuidance de traiter certains de troll à mots à peine couverts et de sous-entendre qu'ils n'y connaissent rien... (là, c'est carrément se moquer du monde !)

Citation Envoyé par erwanlb Voir le message
Juste que la avec ou sans ORM c'est pareil sauf pendant le développement où t'as pas besoin de t'arracher les cheveux avec des requêtes SQL...
Pas besoin d'être un expert en SQL pour faire des choses assez puissantes avec (il est bien sûr nécessaire de connaître les bases, mais il faut pas déconner non plus : c'est pas inhumain de connaître la différence entre un INNER, un OUTER et FULL join...).

C'est seulement quand les projets deviennent un peu sérieux (le genre de projet sur lesquels tu n'as, de ton propre aveu, jamais eu l'occasion de travailler) qu'on a besoin de regarder plus profondément dans les détails techniques du SGBD.

Si on a la chance d'avoir un collègue DBA (dans les petites entreprises, ce n'est pas toujours le cas et les développeurs jouent de rôle de factotum pour tout ce qui est ressources IT) c'est à ce moment qu'il faut se tourner vers lui pour discuter de son problème (et dans le pire des cas, la développeur et le DBA tombent d'accord : c'est l'architecte qui a pondu une abomination et maintenant il faut faire avec et bidouiller pour que ça ne plante pas trop).

Mais bon, quand on atteint ce niveau, c'est clair que ça ferait déjà longtemps que les ORM auraient été complètement à la ramasse...

Citation Envoyé par erwanlb Voir le message
En tout cas si les ORM existent et sont utilisés (c'est quand même pas des outils à l'abandon) c'est qu'ils sont utiles...
Oui, les ORM ont leur utilité, au même titre que tous ces IDE qui permettent de faire du RAD (Rapid Application Development).

Ce qui m'a toujours amusé dans l'acronyme "RAD", c'est que cela ne veut pas dire "Développement d'Applications Rapides (comme on pourrait le penser de prime abord), mais "Développement Rapide d'Applications". Et dans les faits, c'est surtout: "Développement Rapide d'Applications (souvent très lentes et pas forcément faciles à maintenir)".

Et dans certains cas, ça se traduit par l'émergence d'un nouveau cycle de développement, que j'appelle "le cycle en 2 temps", malheureusement de plus en plus en vogue:

1er temps:
- l'entreprise exprime un besoin, elle fait un appel d'offres
- un consultant arrive et propose sa solution
- le consultant fait du RAD et respecte les délais
- le client est content, le consultant touche son gros chèque
- on met la solution en prod

2ème temps:
- au bout d'un certain temps d'exploitation, les problèmes de volumétrie/charge apparaissent
- on fait appel à un "spécialiste" pour corriger les défauts de "cette grosse m**** d'application" (dixit les utilisateurs)
- au bout d'un moment (3 ou 4 entreprises où on retrouve le même genre de problème), le "spécialiste" en a ras le c*l de devoir essuyer les m***** de ces consultants à la c*n

J'ai volontairement mis le terme "spécialiste" entre guillemets. En fait, ce qui en fait "spécialiste", c'est qu'il sait se retrousser les manches plutôt que d'utiliser des outils pour gamins censés lui mâcher le travail...

Il existe une variante, qui est le cycle en 3 temps. C'est la même chose que le cycle en 2 temps, mais avec une extension:

3ème temps:
- on sous-traite les évolutions du système dans un pays du tiers-monde où les gens s'en fichent parce qu'ils sont payés au lance-pierre pour travailler sur des applications où tout le monde a jeté l'éponge depuis longtemps
- on demande au dernier spécialiste en place de faire un "transfert de connaissances"
- si ce n'est pas déjà fait dans le 2ème temps (des raisons personnelles qui l'ont contraint à rester), le spécialiste se casse en disant à tout le monde d' "aller se faire ***** avec un ***** pendant qu'un ****** vous ***** le *****... " (utilisez votre générateur d'insultes préféré pour remplir les blancs)

Donc oui, les ORM et autres outils de RAD ont leur utilité : lancer la première phase du cycle en 2 ou 3 temps (c'est-à-dire pondre rapidement des applis, toucher son gros chèque et aller f**tre sa m***** ailleurs avant que les choses ne devennent un minimum sérieuses et que l'appli ne vous explose à la g*****).

Cordialement,

P.
11  5 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 07/12/2012 à 19:21
Citation Envoyé par Bousk Voir le message
Je n'ai jamais entendu parler des "formes normales", après rapide recherche, wikipedia, ça me dit toujours rien.
Disons que, à l'instar de monsieur Jourdain (Le Bourgeois Gentilhomme, Molière) faisait de la prose sans le savoir, certains développeurs font des formes normales sans le savoir : soit ils ont appris la BDD sur le tas, soit ils savent mettre en pratique mais ont oublié les définitions théoriques depuis longtemps.

Citation Envoyé par Bousk Voir le message
Alors on se plaint des "chef de projet" et autres profanes qui demandent à un dev web de faire des requêtes SQL complexes ou réparer l'imprimante, mais mettre tous les informaticiens dans le même panier à ce niveau me parait pas plus malin qu'eux..
La faute à toutes ces oeuvres de fiction (surtout au cinéma) qui représentent les informaticiens comme des gens capables de tout faire, y compris s'infiltrer dans les réseaux les plus sécurisés du monde en 30 secondes; et les ordinateurs comme "des boites magiques qui peuvent tout faire, et avec une interface en 3D temps réel"...

Partant de ce principe, un informaticien ça peut tout faire et c'est interchangeable...

Comme je dis souvent : "ça vous viendrait à l'idée de demander à un dentiste de faire une opération du cerveau ? Non ? Pourtant dans les deux cas c'est bien de la chirurgie ? Et bien en informatique, c'est pareil..."
6  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 15/08/2012 à 19:01
Citation Envoyé par erwanlb Voir le message
En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....
Un des problèmes que j'ai déjà rencontré avec l'utilisation de certains ORM était l'utilisation systématique de "select *", donc oui, au niveau perf on peut faire mieux
Perso j'ai pu faire des benchmarks d'ORM et j'arrivai à des ratio assez important en fonction du nombre d'éléments retournés*

Pour l'optimisation, je parle de transmettre l'ensemble des requêtes sql au dba pour voir si il ne peut pas ajouter des index, créer certaines vues (si ce n'est pas deja fait) ...
Ca permet une meilleur communication entre les différentes postes qui interviennent sur le projet (on va pas demander au dba d'apprendre le langage doctrine, ou autre...)

* j'avais fait une simple page bouclant sur 100 000 articles, et écrivant le titre, l'auteur et la catégorie dans un fichier texte, et on pouvait voir une différence très importante entre les ORM
5  0