Affichage des résultats du sondage: Rencontrez-vous des réticences d'usage des outils de mapping O/R de vos DBA

Votants
46. Vous ne pouvez pas participer à ce sondage.
  • Non, pas de réticence du tout

    23 50,00%
  • Oui, des réticences au départ mais plus maintenant

    9 19,57%
  • Oui, des réticences et même que l'on ne peut pas utiliser ces outils

    14 30,43%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 3 123 DernièreDernière
  1. #1
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut Comment sont perçus les outils de mapping Objet / Relationnel (JPA, Hibernate, etc.) par vos DBA ?

    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.

  2. #2
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    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

  3. #3
    Expert éminent sénior


    Profil pro
    Inscrit en
    octobre 2003
    Messages
    7 858
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 7 858
    Points : 34 153
    Points
    34 153

    Par défaut

    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 ?

  4. #4
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    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.

  5. #5
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 268
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 268
    Points : 2 500
    Points
    2 500

    Par défaut

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

  6. #6
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    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.

  7. #7
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut

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

  8. #8
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 268
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 268
    Points : 2 500
    Points
    2 500

    Par défaut

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

  9. #9
    Membre expert
    Avatar de GLDavid
    Homme Profil pro
    LIMS manager, bio/chemoinformatique
    Inscrit en
    janvier 2003
    Messages
    2 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : LIMS manager, bio/chemoinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 691
    Points : 3 316
    Points
    3 316

    Par défaut

    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.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  10. #10
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut

    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.

  11. #11
    Membre expert
    Avatar de GLDavid
    Homme Profil pro
    LIMS manager, bio/chemoinformatique
    Inscrit en
    janvier 2003
    Messages
    2 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : LIMS manager, bio/chemoinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 691
    Points : 3 316
    Points
    3 316

    Par défaut

    Hello

    Citation Envoyé par ego Voir le message
    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.
    Merci pour ces infos mais je n'ai jamais dit que ça permettait d'aller plus vite côté SQL. J'ai bien compris qu'on s'affranchit du SQL mais que ça n'accélerait pas les requêtes SQL. C'est une autre manière d'interroger la base.
    Maintenant, tu mentionnes que cette solution apporte un niveau d'abstraction. Mouais... Franchement, il me semble que la création des tables et le fait de produire un schéma relationnel est déjà une abstraction. Autre chose, si ces frameworks miment les tables en objets, dites, pour des grosses bases de données (>100 tables) votre application doit grossir méchamment, non ?
    Bref, j'attends plus d'être convaincu par ces frameworks. Je comprends que des gens soient fâchés par SQL mais à mon humble avis, c'est pas demain la veille que vous vous débarasserez du langage qui a permis d'interroger clairement une base.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  12. #12
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    J'aime beaucoup SQL, je n'ai rien à lui reprocher en tant que langage de requête, mais l'intérêt d'un orm n'est pas là.
    L'orm permet une meilleure isolation entre les données manipulées par l'application et la base de données. On passe d'une base de données Oracle à une DB2 ou MySQL sans l'ombre d'une modification.
    Un autre avantage de l'orm est la possibilité d'avoir une classe unique (dérivée) pour les opérations CRUD (strictement rien de spécifique à coder grâce aux génériques (vive java 1.5 !)
    Pour ce qui est de l'extraction des données, les query proprement dit, on peut faire autant de chose qu'en SQL, on raisonne en propriété de la classe plutôt qu'en jointure mais globalement, lorsqu'on consulte le SQL généré, on n'aurait que très rarement écrit autre chose "à la main".
    Ensuite il y a le gros avantage des propriétés "lazy loadées". C'est tout de même super intéressant d'avoir la possibilité de définir un graphe d'objets et de se dire qu'on n'exécutera la requête d'extraction que si l'objet est demandé explicitement, plus loin dans les couches de l'application. Dans ce cas, effectivement, une nouvelle requête est lancée (qui coûtera du temps, c'est clair) mais au moins, elle ne sera lancée QUE si on en a besoin.
    Et rien n'empêche l'application si besoin d'influer à la demande sur le chargement tardif pour éviter cela.
    Bref, surtout des avantages, que peux d'inconvénients...

  13. #13
    Membre expert
    Avatar de GLDavid
    Homme Profil pro
    LIMS manager, bio/chemoinformatique
    Inscrit en
    janvier 2003
    Messages
    2 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : LIMS manager, bio/chemoinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 691
    Points : 3 316
    Points
    3 316

    Par défaut

    Hello

    Citation Envoyé par OButterlin Voir le message
    J'aime beaucoup SQL, je n'ai rien à lui reprocher en tant que langage de requête, mais l'intérêt d'un orm n'est pas là.
    L'orm permet une meilleure isolation entre les données manipulées par l'application et la base de données. On passe d'une base de données Oracle à une DB2 ou MySQL sans l'ombre d'une modification.
    Un autre avantage de l'orm est la possibilité d'avoir une classe unique (dérivée) pour les opérations CRUD (strictement rien de spécifique à coder grâce aux génériques (vive java 1.5 !)
    Pour ce qui est de l'extraction des données, les query proprement dit, on peut faire autant de chose qu'en SQL, on raisonne en propriété de la classe plutôt qu'en jointure mais globalement, lorsqu'on consulte le SQL généré, on n'aurait que très rarement écrit autre chose "à la main".
    Ensuite il y a le gros avantage des propriétés "lazy loadées". C'est tout de même super intéressant d'avoir la possibilité de définir un graphe d'objets et de se dire qu'on n'exécutera la requête d'extraction que si l'objet est demandé explicitement, plus loin dans les couches de l'application. Dans ce cas, effectivement, une nouvelle requête est lancée (qui coûtera du temps, c'est clair) mais au moins, elle ne sera lancée QUE si on en a besoin.
    Et rien n'empêche l'application si besoin d'influer à la demande sur le chargement tardif pour éviter cela.
    Bref, surtout des avantages, que peux d'inconvénients...
    Ta description est bien faite et je te remercie de cette réponse intéressante. Je le vois alors plus comme un outil pour développeur, pas tellement pour DBA. Si ça peut vous aider sans vous contraindre à des requêtes SQL parfois compliquée, je peux comprendre l'approche. Tout est question de goût et si un développeur préfère cette approche plutôt que du SQL pour faire un query, je ne rien qui m'empêcherait de lui autoriser un tel accès.
    Mais, de mon côté DBA, vous comprendrez que je n'ai pas trop l'utilité de ces outils. Par contre, je l'accepterai du côté développeur seulement pour des queries type SELECT.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  14. #14
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par GLDavid Voir le message
    Mais, de mon côté DBA, vous comprendrez que je n'ai pas trop l'utilité de ces outils. Par contre, je l'accepterai du côté développeur seulement pour des queries type SELECT.
    C'est dommage, d'un point de vue gain de développement c'est surtout sur la partie CRUD qu'on gagne...
    Dans la mesure où la partie requêtes est généralement spécifique à l'ihm (ou à la fonction), on est là plus proche des requêtes sql natives (avec le lazy loading en moins)...

    Je dirais que pour la "Gestion" d'un enregistrement db, il est plus rare de ne vouloir mettre à jour qu'une seule colonne (ou un jeu de colonnes), donc limiter l'usage d'un CRUD n'est pas trop justifiée. (je ne dis pas que le cas ne se présente pas, l'évolution d'un statut en est un parfait exemple)
    Cette limite est vraie surtout pour la mise à jour, un peu pour la création, et pas du tout pour la suppression... pourquoi se priver pour si peu...

  15. #15
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    Ok en passant par un trigger, mais de base, on ne peut pas faire d'insert ou d'update sur une vue.
    Au minimum il faut préciser "on peut avec un trigger" plutôt que d'être péremptoire...

  16. #16
    Expert confirmé

    Homme Profil pro
    SDE
    Inscrit en
    août 2007
    Messages
    2 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : SDE

    Informations forums :
    Inscription : août 2007
    Messages : 2 013
    Points : 4 538
    Points
    4 538

    Par défaut

    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.
    http://alaindefrance.wordpress.com
    Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
    SDE at BitTitan

  17. #17
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

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

  18. #18
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 490
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 490
    Points : 8 505
    Points
    8 505
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par skuatamad Voir le message
    Et qu'en est il des bases (et c'est souvent le cas) exploitées par plusieurs applications ?
    Comment la 2ème application qui n'est pas développée dans le même langage peut elle bénéficier du développement codée dans le layer par la 1ere ?
    On peut arriver là au besoin d'implémenter côté SGBDR...
    Tout dépend des contraintes liées au partage entre plusieurs applications.
    Dans le cas d'applications java, on peut passer (par exemple) par des EJB façade pour gérer ça proprement. Si on a d'autres langages, les web services peuvent également apporter des solutions... Les procédures stockées également...
    Il y a N façons de faire, il ne s'agit pas de dire de facto qu'une est LA solution est les autres de la daube (façon SQLPro), ça ne sert personne, surtout pas l'auteur d'une telle affirmation qui le rend peu crédible

  19. #19
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 824
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 824
    Points : 7 075
    Points
    7 075

    Par défaut

    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.

  20. #20
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 256
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 1 256
    Points : 1 436
    Points
    1 436

    Par défaut

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

Discussions similaires

  1. Réponses: 11
    Dernier message: 01/04/2010, 17h27
  2. Quel outil de mapping objet-relationnel choisir ?
    Par mamelouk dans le forum Persistance
    Réponses: 63
    Dernier message: 21/08/2008, 12h11
  3. Etat des lieux des outils de mapping objet/relationnel (ORM)
    Par Exsilius dans le forum Général Dotnet
    Réponses: 12
    Dernier message: 12/02/2008, 08h50
  4. Outil de mapping objet/relationnel OR not ?
    Par Exsilius dans le forum Général Dotnet
    Réponses: 5
    Dernier message: 01/02/2007, 18h52
  5. Réponses: 2
    Dernier message: 02/08/2005, 13h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo