Discussion :

[DrHelmut]

J'étais 100% pour les ORM, mais finalement à l'usage je préfère largement un bon vieux Spring JDBC... dans presque tous les cas !

Pourquoi ?
Principalement à cause du manque de souplesse des frameworks ORM, mais également à cause de la syntaxe sql modifiées (HQL ou autre)
Certes, l'abstraction de la base de donnée cible est une très bonne chose, pour gérer la pagination par exemple; mais selon le projet, le choix de la base de données cible est souvent clairement défini voire contraint, donc pourquoi s'embetter à écrire des requêtes avec les attribut objets au lieu des champs de la table ?

En fait, je pense surtout qu'on a trop facilement tendance à vouloir à tout prix utiliser un framework ORM sur n'importe quel projet et en cela, c'est une mauvaise chose.

Dans quelques cas, un Hibernate-like est en effet un atout majeur; dans d'autres cas, ça complique plus qu'autre chose...

[CinePhil]

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à !

[Lyche]

Au vu de l'ensemble de la discussion, il semble que la plupart des intervenant 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à !

De toute façon, il ne faut pas se leurrer, la plupart (pour ne pas dire tous) des générateurs de code, pondent des trucs absolument abject en terme de lisibilité et d'optimisation de code SQL.

Ce genre de logiciel est surtout prévu pour que des personnes ne connaissant pas la BDD d'exploiter des bases sans avoir besoin d'un dev en permanence derrière... par contre, bonjour les catastrophe que j'ai pu voir...

[pmithrandir]

De mon coté, souvent très à l'aise avec les requetes SQL, les ORM me font mal aussi. J'y vois malgré tout quelques avantages :
- le CRUD est généré, stable et sécurisé.(ce qui évite pas mal de soucis quand même...)
- On peut maintenant faire quelques requetes avec des paramètres un peu complexe (or et and mélangé, count, max, groupby...)
- on a la possibilité de faire ses requetes soit même si on a vraiment besoin.

L'avantage que j'y vois, c'est une amélioration énorme pour tous les developeurs qui ne pige rien du tout au SQL, au moins il n'introduisent pas de faille toutes les 2 heures...

J'ai essayé Hibernate, doctrine et propel. Mais la dernière version de doctrine me semble au dessus des autres que j'ai esssayé.

[Lyche]

L'avantage que j'y vois, c'est une amélioration énorme pour tous les developeurs qui ne pige rien du tout au SQL, au moins il n'introduisent pas de faille toutes les 2 heures...

Je vais prêcher pour ma paroisse

Mais... que fou quelqu'un qui ne connait rien au SQL dans une BDD?
C'est comme si on me demandait de dev un site web from scratch... j'y connais que dalle... intérêt -> 0; Soucis générés -> inombrables...

Personnellement, je suis pour la séparation des jobs et des tâches. L'informatique est un monde suffisament vaste et complèxe pour se permettre d'avoir des spécialistes et non des types qui touchent un peu à droite et un peu à gauche. D'autant que les BDD, c'est pas que c'est un peu le socle de toutes les applications (ou prèsque) et que confier ce genre de chose à des gens qui n'y connaissent rien (ou pas assez ) c'est juste catastrophique, et je vois ça tous les jours dans mon boulot, ou les dev web font des BDD à la "vas comme je te pousse" sans normes, sans connaitre les petits plus qui font que la BDD vas être stable et performante...

Bref, comme je le souvent dis, chacun son taf..

[Loceka]

Mais... que fou quelqu'un qui ne connait rien au SQL dans une BDD?

Ben ça faut le dire à ceux qui gèrent les ressources dans les entreprises.
Parce que, d'après mon expérience, j'ai jamais vu un "expert SQL" dans un projet. C'étaient toujours les dev (web ou autre) qui se farcissaient les requêtes SQL, quelque soit leur niveau là-dedans.

[pmithrandir]

Le problème Lyche, c'est que dans 95% des applications que j'ai vu, le code métier est intimement lié à la bdd. Et autant on arrive a justifier un expert SQL pour des requetes complexe, autant pour les opérations simples (CRUD) la on peut s'accrocher.

De la même façon, j'ai déjà été confronté a des dev persuadé d'être bon, mais pas foutu de comprendre ce qu'est la forme normale 3 et de l'appliquer... ("on doit dénormaliser, il y a 100 000 lignes... c'est trop..")

Dans ces cas là, tu fais quoi, tu leur dit qu'ils connaissent pas leur métier ? Pas facile dans un équipe. On se sent vite tout seul si on attaque les autres a ce niveau là.

Et puis même, payer un expert SQL pour faire des opérations simples et automatisables, juste pour éviter d'introduire des problèmes d'injections... ca fait cher à force.

La, avec ce genre de système, on arrive a faire en sorte d'éloigner els importuns des problème de BDD, et on laisse l'expert SQL se débrouiller avec les problématiques de l'ORM, ou des requetes complexe, ce qu'il saura faire au final.

[Lyche]

Ben ça faut le dire à ceux qui gèrent les ressources dans les entreprises.
Parce que, d'après mon expérience, j'ai jamais vu un "expert SQL" dans un projet. C'étaient toujours les dev (web ou autre) qui se farcissaient les requêtes SQL, quelque soit leur niveau là-dedans.

Boah, dans ma boite on a 4 personnes spécialites de SQL Server + 8Spécialites de Oracle + 3 progress... + 2DBA et c'est les devweb qui font les BDD des sites webs...
J'ai beau gueuler, dire que c'est à nous de faire les bases, ou au moins de valider les models et la gestion des ressources serveurs..

C'est une habitude à faire rentrer dans la tête des gens (surtout des chefs de projet en fait).

Chacun son métier.
J'irais pas demander du pain à mon boucher, ça me viendrait même pas à l'esprit... apparement, en informatique tout le monde peut tout faire... Même un dev peut réparer un PC c'est dire ^_^

[Lyche]

Le problème Lyche, c'est que dans 95% des applications que j'ai vu, le code métier est intimement lié à la bdd. Et autant on arrive a justifier un expert SQL pour des requetes complexe, autant pour les opérations simples (CRUD) la on peut s'accrocher.

De la même façon, j'ai déjà été confronté a des dev persuadé d'être bon, mais pas foutu de comprendre ce qu'est la forme normale 3 et de l'appliquer... ("on doit dénormaliser, il y a 100 000 lignes... c'est trop..")

Dans ces cas là, tu fais quoi, tu leur dit qu'ils connaissent pas leur métier ? Pas facile dans un équipe. On se sent vite tout seul si on attaque les autres a ce niveau là.

Et puis même, payer un expert SQL pour faire des opérations simples et automatisables, juste pour éviter d'introduire des problèmes d'injections... ca fait cher à force.

La, avec ce genre de système, on arrive a faire en sorte d'éloigner els importuns des problème de BDD, et on laisse l'expert SQL se débrouiller avec les problématiques de l'ORM, ou des requetes complexe, ce qu'il saura faire au final.

Le truc c'est qu'on travail dans un domaine ou l'optimisation est nécessaire... voir un devweb faire ses testes d'apprentissage sur une base de prod (j'ai le cas dans ma boite) c'est juste, incensé. Et puis, je parle pas forcément d'experts mais de personnes spécialisées.
Comme un devweb n'est pas forcément un expert, mais avec le temps il apprends son métier et donc améliore son code, sa vitesse de dev et son organisation, je pense qu'on devrait faire pareil en BDD. C'est à dire avoir des personnes qui font de la BDD et qui ont les soucis des ressources et d'une bonne modélisation quand ils développent, qui s'organisent dans les bases à leur manière et qui ne sont pas obligés de subir les choix des devweb...

Je comprends que ce soit une question de facilité, ou autre... mais c'est justement en choisissant la facilité qu'on en arrive aux soucis.

Pis regarde, je suis pas un expert (pas encore) et je ne fais que du SQL toute la journée. On a des équipes prévues pour les BDD, mais les devweb (on a pas de devapp) font quand même les BDD sans nous prévenir, sans aucune nomenclature malgré les consignes du chef, y'a quand même un soucis de fond.. et ce n'est pas uniquement dans mon entreprise

[DrHelmut]

L'avantage que j'y vois, c'est une amélioration énorme pour tous les developeurs qui ne pigent rien du tout au SQL, au moins il n'introduisent pas de faille toutes les 2 heures...

Tu soulèves un lièvre là : comment se fait-il qu'on puisse estimer qu'il n'y a pas besoin de connaitre le SQL pour faire de la persistance en base de données relationnelle ?
L'introduction de faille ne me parait pas un argument super pertinent, pas besoin d'ORM dans le monde java pour utiliser des façons propres de gérer ses requêtes SQL....

Bref, dans tous les cas, je ne confierais pas la réalisation de la couche dao d'une appli à un mec qui ne maitrise pas a minima les 3 formes normales et tout ce qui va avec... ne pas maitriser ces fondamentaux, c'est... limite honteux je trouve pour un informaticien !

[Lyche]

Tu soulèves un lièvre là : comment se fait-il qu'on puisse estimer qu'il n'y a pas besoin de connaitre le SQL pour faire de la persistance en base de données relationnelle ?
L'introduction de faille ne me parait pas un argument super pertinent, pas besoin d'ORM dans le monde java pour utiliser des façons propres de gérer ses requêtes SQL....

Bref, dans tous les cas, je ne confierais pas la réalisation de la couche dao d'une appli à un mec qui ne maitrise pas a minima les 3 formes normales et tout ce qui va avec... ne pas maitriser ces fondamentaux, c'est... limite honteux je trouve pour un informaticien !

Oui et non, le premier reproche est quand même à mettre sur de nombreux profs, qui enseignent encore du SQL89 et qui sont pas foutu de faire des cours explicites (et je parle en connaissance de cause, j'aide des personnes en formation à maitriser le relationnel et les BDD)
Quand je vois les cours de certains profs... je vous jure, j'aurais envie de prendre une journée de congé pour aller lui parler et lui explique qu'il forme des personnes aux mauvaises pratiques avant même leur entrée dans le monde pro...

Et puis tout le monde n'est pas forcément familier avec l'algèbre de bool, une des bases nécessaires à la maitrise de la logique ensembliste et aux normes des bases de données.

[el_slapper]

(.../...)Et puis tout le monde n'est pas forcément familier avec l'algèbre de bool, une des bases nécessaires à la maitrise de la logique ensembliste et aux normes des bases de données.

Je travaille très peu sur BD, alors j'aurais du mal à avoir une opinion sur les ORM(je fais 3 requêtes simples par an, pas besoin d'ORM).

Mais là, je pense que tu ne vas pas assez loin dans ton raisonnement : quelqu'un qui n'est pas à l'aise avec la logique, avec l'algèbre de bool, n'a pas sa place dans notre métier. Or on trouve plein de gens en sortie d'école, diplomés, qui sont infoutus de penser logiqiement. Tout dans notre métier découle de la logique, depuis la spécification jusqu'au test final, en passant par l'architecture, le codage, la persistance, le réseau, et j'en oublie.

Mais nous avons besoin d'informaticiens, alors nous laissons des gens incapables de l'être entrer en école, et en sortir avec un diplôme. Juste parcequ'ils ne sont pas nuls en maths.

Moi je pense que les maths, c'est vaste, mais qu'en informatique, la part nécéssaire n'en est qu'un tout petit morceau(logique et algèbre de boole, essentiellement) - et qu'on devrait trier prioritairement la-dessus. Sans quoi, on continuera encore longtemps à se trainer des problèmes causés par des gens certainement très bien, mais pas à leur place.

[Lyche]

Je travaille très peu sur BD, alors j'aurais du mal à avoir une opinion sur les ORM(je fais 3 requêtes simples par an, pas besoin d'ORM).

Mais là, je pense que tu ne vas pas assez loin dans ton raisonnement : quelqu'un qui n'est pas à l'aise avec la logique, avec l'algèbre de bool, n'a pas sa place dans notre métier. Or on trouve plein de gens en sortie d'école, diplomés, qui sont infoutus de penser logiqiement. Tout dans notre métier découle de la logique, depuis la spécification jusqu'au test final, en passant par l'architecture, le codage, la persistance, le réseau, et j'en oublie.

Mais nous avons besoin d'informaticiens, alors nous laissons des gens incapables de l'être entrer en école, et en sortir avec un diplôme. Juste parcequ'ils ne sont pas nuls en maths.

Moi je pense que les maths, c'est vaste, mais qu'en informatique, la part nécéssaire n'en est qu'un tout petit morceau(logique et algèbre de boole, essentiellement) - et qu'on devrait trier prioritairement la-dessus. Sans quoi, on continuera encore longtemps à se trainer des problèmes causés par des gens certainement très bien, mais pas à leur place.

Je parlais pour le métier de la BDD, pas du développement en générale. Les contraintes des bases de données sont en grande partie réglées par une bonne maitrise de l'algèbre de bool.

[Bluedeep]

. Les contraintes des bases de données sont en grande partie réglées par une bonne maitrise de l'algèbre de bool.

Pas vraiment, non. Cela relève plutôt de l'algèbre relationnel (issu de la theorie des ensembles de Cantor) et sa parenté avec l'algèbre de Boole est assez ténue.

[Bousk]

Bref, dans tous les cas, je ne confierais pas la réalisation de la couche dao d'une appli à un mec qui ne maitrise pas a minima les 3 formes normales et tout ce qui va avec... ne pas maitriser ces fondamentaux, c'est... limite honteux je trouve pour un informaticien !

Je n'ai jamais entendu parler des "formes normales", après rapide recherche, wikipedia, ça me dit toujours rien. Et ça a l'air un peu spécifique aux problèmes de BDD. Ouf, j'en touche jamais.

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

[pcaboche]

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.

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

[SuperCed]

Avantages d'un ORM :
- s'occupe de la sécurité à la place du développeur
- permet de changer de SGBD
- génération des migrations

Inconvénients :
- Performances parfois désastreuses
- Limite les possibilités dans certains sgbd
- Temps d'apprentissage
- Temps de codage et debug plus longs

Pour conclure, je suis plutôt contre et je trouve qu'on s'en sort finalement mieux sans ORM.

[Namica]

Je n'ai jamais entendu parler des "formes normales", après rapide recherche, wikipedia, ça me dit toujours rien. Et ça a l'air un peu spécifique aux problèmes de BDD. Ouf, j'en touche jamais.
...

Et oui, c'est pour les db relationelles : https://fr.wikipedia.org/wiki/Forme_...ationnelles%29

[rawsrc]

Avantages d'un ORM :
- permet de changer de SGBD

ça m'a toujours fait marrer cet argument asséné à loisir.
Changer le moteur de base de données d'une application d'entreprise c'est généralement un sacré chantier, ORM ou pas ORM.
Et dire qu'avec un ORM ça se fait en deux coups de cuillère à pot c'est prendre les gens pour des c.ns.

Déjà que souvent c'est un sacré bordel, alors avoir à gérer la couche ORM par dessus c'est encore se prendre la tête pour que dalle.

[_skip]

ça m'a toujours fait marrer cet argument asséné à loisir.
Changer le moteur de base de données d'une application d'entreprise c'est généralement un sacré chantier, ORM ou pas ORM.
Et dire qu'avec un ORM ça se fait en deux coups de cuillère à pot c'est prendre les gens pour des c.ns.

Déjà que souvent c'est un sacré bordel, alors avoir à gérer la couche ORM par dessus c'est encore se prendre la tête pour que dalle.

Dans le même genre on a

• L'architecture 3 tiers magique qui permet de remplacer à loisir la source de données SGBD par un webservice voire un fichier XML sans modifier le fonctionnement des couches supérieures.
• L'ORM qui décide du schéma et gère les migrations tout seul.
• La couche métier 100% orientée objet qui fait abstraction du système de stockage

Pour moi tout cela fait partie d'une série de mythe créés par des auteurs de bouquins qui sautent dès qu'on dépasse le stade de l'application CRUD triviale avec 3 entités. Et Dieu sait les dizaines de millions que ces dogmes ont du coûter, si on imagine tous les projets où dans la volonté d'obéir à de soi-disant bonnes pratiques de conception, on a voulu les appliquer sans discernement.