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 !

Persistance en Java : Perception des outils de mapping Objet / Relationnel

. Votre DBA est-il réticent ?

Le 15 novembre 2009 à 12:14, par ego

44 commentaires

65PARTAGES

Voter pour

1

Voter contre

0

Rencontrez-vous des réticences d'usage des outils de mapping O/R de vos DBA

Non, pas de réticence du tout		50 %
Oui, des réticences et même que l'on ne peut pas utiliser ces outils		29 %
Oui, des réticences au départ mais plus maintenant		21 %

Voter 48 votants

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.

Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

44 commentaires

Commenter Signaler un problème

Membre éclairé

Le 18/11/2009 à 15:41

Bonjour,

En regardant les bases de données que je gère, le souci ne vient pas de l'utilisation d'un ORM mais du fait qu'on confie à des apprentis-jardiniers la modélisation des données!!!

Après on nous demande de tuner des installs pour améliorer les performances et on fait ce qu'on peut mais on ne peut pas faire de miracle...

Ensuite, les ORM ont un inconvénient certain pour moi : ça fait croire aux développeurs qu'ils n'ont rien à connaître en ce concerne les BDD. Du coup, on se retrouve à débugguer l'appli à leur place parce qu'ils ont fait une faute de frappe dans un fichier de config et parce qu'ils sont incapables de se connecter à une base de données en direct pour tester leur requête!

Voilà pour moi!

Arkhena

Voter pour

1

Voter contre

0

Modérateur

Le 15/11/2009 à 12:57

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

Voter pour

0

Voter contre

0

Expert éminent sénior

Le 15/11/2009 à 13:16

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 ?

Voter pour

0

Voter contre

0

Modérateur

Le 15/11/2009 à 15:15

Citation

Envoyé par Ricky81

Voir le message

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.

Voter pour

0

Voter contre

0

Membre expert

Le 15/11/2009 à 18:17

Citation

Envoyé par OButterlin

Voir le message

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

Voter pour

0

Voter contre

0

Modérateur

Le 15/11/2009 à 18:57

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.

Voter pour

0

Voter contre

0

Rédacteur

Le 15/11/2009 à 20:25

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

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

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

Voter pour

0

Voter contre

0

Membre expert

Le 15/11/2009 à 20:57

Citation

Envoyé par OButterlin

Voir le message

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

Voter pour

0

Voter contre

0

Expert confirmé

Le 16/11/2009 à 8:49

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.

@++

Voter pour

0

Voter contre

0

Rédacteur

Le 16/11/2009 à 9:23

Mais l'objectif n'est pas d'aller "plus vite" côté SQL
C'est de fournir un niveau d'abstraction plus élevé que SQL pour écrire des requêtes vers la base. On utilise les même termes qu'au niveau objet et c'est le framework qui fait la traduction.
C'est vrai que le framework apporte des éléments pour les perfs comme les caches de premier et second niveau mais je dirai que l'essentiel n'est pas là.
C'est comme quand on a inventer le C afin de ne plus écrire de l'assembleur, l'idée première était de permettre d'écrire plus facilement.
Côté base de données, quand on a des problèmes de perfs, c'est plus à cause d'une mauvaise conception du code et de la base elle-même qu'à cause des requêtes elles-mêmes.

Voter pour

0

Voter contre

0

Commenter Signaler un problème