Discussion :

[ego]

Bonjour,

concernant les outils de mapping O/R, JPA, Hibernate et autres, rencontrez-vous des réticences de la part de votre DBA ? Des "peurs" du genre : Ouhai avec ces outils, on ne maitrise pas le SQL exécuté, il est préférable d'avoir les requêtes en dur au moins on sait ce que l'on fait

Si bien sûr il y a des DBA (des vrais de vrais ) qui peuvent se prononcer, ça serait encore mieux

Merci à vous

[Edit]
Pour information, un débat existant complémentaire qui traite du point de vue particulier de la performance : Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?

N'hésitez pas à faire un retour d'expérience sur d'autres axes de perception / évaluation.

[OButterlin]

Non chez nous...

Ce n'est pas vraiment le rôle d'un DBA de se prononcer sur une solution technique, il est plutôt là pour optimiser la base et la "gérer" au sens large.

De plus, ce n'est pas hibernate ou un orm qui génère forcément une diminution des performances mais l'application qui peut être plus ou moins gloutonne en requête DB ou qui n'optimise pas ses accès.
Ce sont plutôt les chef de projets qui expriment des craintes par rapport aux orm (surtout ceux qui ne veulent pas se remettre en cause).
Pour ce qui est de la "non maîtrise" du code, c'est plus ou moins vrai...
On peut tout de même agir sur la manière de générer la requête.
J'ai fait des applications de gestion avec Hibernate et d'autres sans.
Je ne sent pas de baisse significative des performances qu'on pourrait imputer à l'ORM

[Ricky81]

Pour information, un débat existant complémentaire qui traite d'un axe particulier (performances) : Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?

[OButterlin]

Pour information, un débat existant complémentaire qui traite d'un axe particulier (performances) : Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?

Je ne l'avais pas vu celui là (et quelque part, après avoir lu les 6 pages, on reste baba). Personnellement, je trouve l'avis totalement partial, visiblement sans pratique d'un orm... bref, un gars qui nous dira que programmer en assembleur c'est vachement plus performant...

Je préfère perdre 100ms pour un traitement particulier que de perdre 3 semaines à essayer de comprendre ce qu'on avait voulu faire et à retrouver la couche impliquée... (mais non, je n'exagère pas )
Quant à l'aspect portabilité (inter-bases), la procédure stockée n'est vraiment pas la panacée.
Bon, pour ne pas paraitre aussi "jusqu'au boutiste" que l'auteur, je dirais pour ma part qu'il vaut mieux tirer partie des avantages des uns et des autres plutôt que de dire "ça c'est de la merde et ça c'est le saint graal".
Rien n'empêche de faire faire 95% du boulot à l'ORM et de passer par des procédures stockées ou du sql natif pour le reste.

[Luc Orient]

...
Ce n'est pas vraiment le rôle d'un DBA de se prononcer sur une solution technique, il est plutôt là pour optimiser la base ...

Optimiser une Base de données sans avoir la connaissance très précise des accès réalisés m'apparaît pour le moins difficile ... mais je pars du postulat, peut être faux après tout, que ces outils de mapping n'offrent pas une bonne visibilité sur le SQL généré ou que ce dernier est trop générique pour être raisonnablement optimisé ...

[OButterlin]

Que veux-tu dire par "visibilité du sql généré" ?
La possibilité de voir ce code ou d'intervenir dessus ?

Hibernate (pour en citer un) permet de faire des choses très précises en terme de requête.
Dans la mesure où on utilise l'orm pour la création/mise à jour des enregistrements (c'est évidement le cas général), il va de soit que ça se fait sur une "entité" représentant un enregistrement complet (on peut également jouer sur les mises à jour cascade pour propager les modifications sur des fils à partir du père). C'est ce qu'on appelle généralement un CRUD. Là, il n'y a guère d'optimisation possible... En JDBC, on pourrait faire plus fin...

Pour la partie extraction des données, on peut par contre faire à peu près ce qu'on veut, ne récupérer que quelques colonnes, etc...
Bref, j'attends de savoir ce que tu voulais dire avant de continuer...

Pour le boulot d'un DBA, je suis bien d'accord qu'il doit connaître la nature des accès pour les optimiser... ce qui ne veut pas dire que son avis dans le choix d'une technologie sera déterminant... Si le projet consistait à développer une application multi-client, multi-bases (cas d'un progiciel), je pense qu'on ne prendrait même pas la peine de le consulter...

Pour le reste, un DBA pourra en analysant la charge du SGBDR définir de nouveaux index ou vue pour optimiser les temps de réponses.

[Luc Orient]

Que veux-tu dire par "visibilité du sql généré" ?
La possibilité de voir ce code ou d'intervenir dessus ?

Les deux mon général ...

Pour le reste, un DBA pourra en analysant la charge du SGBDR définir de nouveaux index ou vue pour optimiser les temps de réponses.

Nous on préfère voir les principaux accès avant ... On fait du préventif plutôt que du curatif ... Même si l'un n'exclut pas l'autre ...

[GLDavid]

Bonjour

Je n'ai pas apporté de réponses.
Et pour cause, je suis, entre autre, DBA PostgreSQL au sein de la société pour laquelle je bosse (société de consultance en bioinformatique en Belgique).
Je n'ai pas d'avis concernant ces solutions de mapping ER->Objets. Je reste encore attaché au SQL et c'est le cas pour les développeurs. On se débrouille plutôt bien en SQL.
Pour le moment, nous ne voyons pas ce que ces API peuvent nous apporter. Manque de connaissance ? Certainement. Il n'empêche que pour le moment, nos clients ne nous demandent pas ces outils. Remarquez que nos clients partent du principe que peu importe le vin tant qu''ils aient l'ivresse. En clair, on a carte blanche sur les outils (tant que ça matche avec leur infra-structure). En interne à présent, étant DBA, je ne suis pas hostile à l'utilisation de ces outils. Je ne demande qu'à voir ce que ça peut apporter de plus. Si ça permet un gain de rapidité par rapport à une requête SQL, pourquoi pas.

@++

[ego]

mais je pars du postulat, peut être faux après tout, que ces outils de mapping n'offrent pas une bonne visibilité sur le SQL généré ou que ce dernier est trop générique pour être raisonnablement optimisé ...

Il n'est pas générique, absolument pas.
Le truc c'est simplement de pouvoir écrire, par exemple si on prend l'exemple d'Hibernate, un ordre simple comme (genre) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Dossier d = getJdbcTemplate().load(12,Dossier.class);

où 12 est la clé primaire du Dossier recherché.

Dans le fichier de mapping, on a décrit par exemple que :

Les objets Dossier sont stockés dans la table TDOSSIER
L'attribut id est stocké dans la colonne ID
L'attribut numero est stocké dans la colonne C-NUM
L'attribut Libellé est stocké dans la colonne N-LIB

Hibernate va alors fabriquer la requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT d.id, d.c-num,d.n-lib FROM tdossier d WHERE d.id = 12

C'est tout.
Il n'y a rien, absolument rien de générique. Tout peut être anticipé en fonction du mapping.
L'idée du langage HQL d'Hibernate, qui est très très proche de SQL, est simplement de permettre de nommer les noms Java des objets/attributs à la place de leur correspondant SQL. Cela permet avant tout l'écriture d'un code "SQL" (HQL donc) proche du fonctionnel mais qui finalement ressemble à ce que l'on aurait écrit en SQL natif.
Dans des cas avec jointures nécessaire, il suffit aussi de faire la jointure en "objet" en mettant une clause where avec égalité des 2 clés primaires des objets et s'il y a une table de jointure, Hibernate génèrera la requête SQL adéquate.
Bref, il n'y a rien de générique ni de magique, tout est régit par le fichier de mapping.
D'ailleurs, il est possible d'activer les traces SQL afin, notamment lors des tests, de demander à logger les ordres SQL effectivement envoyés.
Dans ces cas plus complexes, on peut parfois même être étonné de l'ordre généré qui est mieux foutu que ce que l'on imaginait faire "à la main".

[Alain Defrance]

Pour moi (mais j'ai peut-être tort), les ORM ne fournissent pas qu'une simplicité d'écriture, et j'irais même jusqu'à dire que ce n'est qu'une petite partie. Travailler en OO avec des bases de données relationnelles nous embête depuis qu'on dit que les base de données relationnelles vont disparaitre (et depuis le temps qu'on le dit et le chemin que çà en prend, on est pas prêt de s'en passer).

Bref le vrai travail d'un ORM est vraiment de faire coller des structures de données objet en relations. A mon sens le mapping est bien plus important que le langage de requête. JPQL c'est bien etc, mais en fin du compte, ça existe déjà depuis très longtemps (le SQL). Certes ils est plus riche (opérateur new, member of, is empty, et bien plus), mais en fin de compte on pourrait s'en tenir au SQL.

[OButterlin]

C'est tout à fait vrai...
Le mapping est LE point important de la modélisation.
On se concentre ici sur l'aspect fonctionnel des données, il ne s'agit pas de mapper tous les "Set" issus de toutes les relations possibles (liées aux clés étrangères de tables sous-jacentes).
On le fait une fois (bien) et on l'utilise partout. Il est largement plus agréable de travailler avec des objets dans un langage objet que d'avoir à N endroits besoin de mapper les colonnes d'un ResultSet vers les types correspondant du langage. Sans compter que là, on retrouve toutes les aberrations liées aux différentes implémentations d'un même type (Date en est un parfait exemple) qui rendent difficile le portage d'une DB vers une autre.

Ensuite, il y a les requêtes (de recherche ou autre). Ici, on peut faire tout ce qui est possible en SQL, il n'a jamais été dit qu'un ORM imposait sa façon de faire, on peut également "mapper" automatiquement une requête native vers un objet...

[_skip]

Et moi je n'utilise un ORM, enfin un mapper plutôt (iBatis) uniquement pour ne pas avoir à écrire trop de plomberie entre la conversion d'une requête JDBC en objet.

Par contre le lazy-loading et les proxys sont tout ce que je déteste en programmation. A titre d'exemple je suis techniquement incapable de considérer des POJO hibernates comme des objets métiers.

C'est un débat philosophique ensuite.

[davcha]

Qu'est-ce que tu entends par "trop de plomberie" ?

[dingoth]

Je n'utilise pas d'ORM, pour autant, je n'estime pas que je fais de la perte de temps. La création des mappings n'est faite qu'une fois également, comme si j'avais un ORM. Je ne comprends pas cet argument qui dit que lorsqu'on n'utilise pas d'ORM, il y a 3000 mappings à faire.

L'argument de la portabilité de la base de données est beau dans les faits, mais perd de son ampleur dans la réalité. Les deux réelles applications à ceci sont la possibilité laissée au client d'utiliser le SGBDR de son choix et la possibilité de changer sa base de données quand on le souhaite. Ceci me pose deux problèmes : on ne sait pas quelle est la base de données du client et l'on doit la supporter. Vouloir prôner l'universalité d'un système est beau dans l'idée, mais a de solide contre-arguments, tel les perfs misérables.

Le jour où un ORM libre créera des stored procs (pour une quelconque BDD) à ma place à partir de mon code Java afin d'avoir l'avantage de la rapidité de développement et des perfs, j'envisagerai peut-être de passer aux ORM (cela existe déjà en système payant). En attendant, je reste à mon système qui, bien que très légèrement plus lent au développement, m'assure des performances excellentes et une séparation des problématiques extrêmement nette.

[Tommy31]

Je n'utilise pas d'ORM, pour autant, je n'estime pas que je fais de la perte de temps. La création des mappings n'est faite qu'une fois également, comme si j'avais un ORM. Je ne comprends pas cet argument qui dit que lorsqu'on n'utilise pas d'ORM, il y a 3000 mappings à faire.

Parce que probablement tu ne travaille pas directement sur ton modèle métier mais sur une vue de celui-ci. Ainsi, tu n'as pas à te pré-occuper de la navigabilité du modèle.

[dingoth]

Au contraire, nous sommes deux à nous occuper du domaine : le programmeur SQL et moi-même.

Nous suivons quelques conventions comme retourner un maximum des ensembles de données identiques, quitte à les remplir par des NULL. Par exemple, si nous voulons uniquement les noms des clients des livres, la stored proc renverra par exemple :

ID : rempli
Prénom : rempli ou NULL si société
Nom : rempli ou NULL si société
Société : rempli ou NULL si particulier
TVA : NULL
Adresse : NULL

etc.

Si c'est cela que tu appelles avoir des vues métier, alors je dis oui.

Rien à voir, mais il était pas autre part, ce sujet ?

[_skip]

Je n'utilise pas d'ORM, pour autant, je n'estime pas que je fais de la perte de temps. La création des mappings n'est faite qu'une fois également, comme si j'avais un ORM. Je ne comprends pas cet argument qui dit que lorsqu'on n'utilise pas d'ORM, il y a 3000 mappings à faire.

Je dirai que l'un des points

L'argument de la portabilité de la base de données est beau dans les faits, mais perd de son ampleur dans la réalité. Les deux réelles applications à ceci sont la possibilité laissée au client d'utiliser le SGBDR de son choix et la possibilité de changer sa base de données quand on le souhaite. Ceci me pose deux problèmes : on ne sait pas quelle est la base de données du client et l'on doit la supporter. Vouloir prôner l'universalité d'un système est beau dans l'idée, mais a de solide contre-arguments, tel les perfs misérables.

Bien dit, tu me croiras si je te dis que tous les logiciels axé données que je connais qui justement se prétendaient multi-base au départ ont fini par devenir mono-base?
La raison est simple, on doit se limiter au plus petit dénominateur commun au niveau fonctionnalité ce qui veut dire quasiment tirer une croix sur le code serveur, de plus il faut tenir compte des spécificités des SGBDR au niveau des DDL entre autres de leur façon de gérer les clefs auto incrémentales et si on veut des fonctionnalités avancées comme la réplication multi-site, là ça peut devenir infernal.
On ajoute à cela les nombreux tests nécessaires au support multi-base, le support client très dépendant de l'environnement de celui-ci, ça peut devenir une charge de travail astronomique pour un gain au final assez faible

je reste à mon système qui, bien que très légèrement plus lent au développement, m'assure des performances excellentes et une séparation des problématiques extrêmement nette.

A ce sujet, IBatis m'a semblé une excellente solution car il permet de profiter de toute la puissance du SQL tout en éliminant certains aspects pénibles du JDBC pur.

Qu'est-ce que tu entends par "trop de plomberie"

La conversion des ResultSet en POJO, et toutes ces choses rébarbatives dont je peux soit me passer, soit sortir du code.

[dingoth]

Bien dit, tu me croiras si je te dis que tous les logiciels axé données que je connais qui justement se prétendaient multi-base au départ ont fini par devenir mono-base?

Oui, c'est le déroulement classique d'un projet :
- Tous les clients utilisent Oracle ?
- Oui, boss, sauf un qui utilise MySQL
- Bon, bah, à partir de maintenant, on ne supporte plus qu'Oracle alors.
- Ah ben zut, boss on aura des perfs nulles avec notre ORM, et puis il nous faudrait un programmeur SQL, ce qui coûte un pont !
- Non, vous continuez comme ça, je trouverais bien quelque chose à dire aux clients inquiets des perfs : c'est mon job ; et pour le gars qui utilise MySQL, je le ferai passer à Oracle.

Je connais bien la problématique. J'avais écrit une longue tartine qui l'incluait, mais au final, j'ai supprimé les trois quarts car c'était presque du hors sujet ici.

A ce sujet, IBatis m'a semblé une excellente solution car il permet de profiter de toute la puissance du SQL tout en éliminant certains aspects pénibles du JDBC pur.

Bien possible : je ne connais pour ainsi dire qu'Hibernate comme ORM. C'est, semble-t-il le plus développé, et donc le seul auquel je m'intéresse en attendant LA fonctionnalité qui me fera passer à l'ORM, c'est à dire la traduction de code Java métier en stored-proc.

La conversion des ResultSet en POJO, et toutes ces choses rébarbatives dont je peux soit me passer, soit sortir du code.

Pour cela, j'ai juste une version modifiée de DBUtils. Le mapping est fait assez rapidement, et sans me casser la tête.

[ego]

C'est vrai qu'il est difficile de faire ressortir l'ironie dans l'écrit...
Je suis d'accord avec toi, c'était une forme (extraterrestre faut croire) d'humour... je ne suis pas attaché au passé, mais je ne l'oublie pas pour autant... les bonnes fondations permettent de bâtir haut et robuste

ok alors pas de soucis

[ego]

je suis attéré par l'extremisme de vos réactions et le design que certains proposent.
S'appuyer sur des proc stockées, c'est franchement pas la solution que j'ai vu dans ma vie d'informaticien depuis maintenant 16 ans. Je suis peut être moi aussi à côté de la plaque mais je ne crois pas avoir fait ou vu de projets avec des proc stockées.
Luc Orient me corrigera mais dans notre boite il ne doit pas y en avoir et nous travaillons dans une TRES TRES grosse entreprise avec de TRES TRES GROS besoins en termes de volume et de transactions/seconde. Et je crois que ça marche.........me semble t-il.
Et puis vous savez, l'informatique va vers de plus en plus d'abstraction et donc travailler au niveau objet même pour déclencher des requêtes en base me parait "normal" (sachant que malgré tout il y a SQL derrière). Mais qui sait, peut être qu'un jour il n'y aura même plus le SQL......oh zut, j'ai dit une grossièreté, non

Pour ceux qui restent collé à leur SQL, vous vous trimballez, si vous faites du Java, avec vos ResultSet dans toute l'application ?
Et pour celui qui fait des proc stock qui renvoie des NULL en fonction de l'objet retourné, moi je mettrai un zéro en terme de conception.
Et mon exemple avec le "select new ClientSimple..." c'est justement fait pour ça = ne pas tout ramener si on n'a pas besoin de tout le Client.

Mais peut être que ceux qui n'ont jamais utilisé d'ORM devraient au moins faire l'essai, pour voir et parler en connaissance de cause.