Publicité

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

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

    23 51,11%
  • Oui, des réticences au départ mais plus maintenant

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

    13 28,89%
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 3 PremièrePremière 123
Affichage des résultats 41 à 54 sur 54
  1. #41
    Membre du Club
    Inscrit en
    décembre 2004
    Messages
    88
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 88
    Points : 45
    Points
    45

    Par défaut

    Finalement, l'utilisation d'ORM c'est un peu choisir Windev comme outil de dev !
    Pas une ligne de code (ou presque), pas de code SQL (commande hlit...).
    Où est donc l'intérêt d'utiliser Java ?

    J'utilise Windev et je code mes requêtes SQL.
    J'ai essayé avec les ordres hlit... hajoute ... et question performance les requêtes SQL sont nettement plus performantes.
    Il faut bien entendu maitriser le SQL.
    En écrivant du code SQL respectant le norme SQL (la vrai, celle qui est respecté par la majorité des SGDB), on peut s'en sortir sans réécrire du code SQL si on change de SGBD.

  2. #42
    Membre du Club
    Inscrit en
    décembre 2004
    Messages
    88
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 88
    Points : 45
    Points
    45

    Par défaut

    Oh j'oubliais !

    Il ne faut pas perdre de vue le besoin client !
    Que veux le client ?
    Une appli qui réponde à ces specs et qui ne mets pas trois plombe à faire les traitements demandés !

  3. #43
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    le parallèle avec Windev n'engage que toi et je ne suis pas certain que ce parallèle soit judicieux ici

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Citation Envoyé par brice01 Voir le message
    Finalement, l'utilisation d'ORM c'est un peu choisir Windev comme outil de dev !
    Pas une ligne de code (ou presque), pas de code SQL (commande hlit...).
    Où est donc l'intérêt d'utiliser Java ?

    J'utilise Windev et je code mes requêtes SQL.
    J'ai essayé avec les ordres hlit... hajoute ... et question performance les requêtes SQL sont nettement plus performantes.
    Il faut bien entendu maitriser le SQL.
    En écrivant du code SQL respectant le norme SQL (la vrai, celle qui est respecté par la majorité des SGDB), on peut s'en sortir sans réécrire du code SQL si on change de SGBD.
    Soyons sérieux, Windev a toujours eu comme point faible sa base. Passer à n'importe quelle autre base apporte un plus à une application Windev et un énorme gain en stabilité.
    Pour le reste, ça fait des choses simplement... mais question performance, on a eu l'occasion (à l'époque) de comparer un exe windev avec la même fonctionnalité Delphi, il n'y avait pas photo (en faveur de Delphi bien sûr ).

    A part ça, un ORM ne veut pas dire "pas de ligne de code", il faut coder les requêtes d'accès, l'aspect transaction, etc... il reste à faire...
    On n'a "juste" pas à faire ce qui n'a aucune valeur ajoutée en terme de fonctionnel (à savoir le lien entre les colonnes et les attributs objets et toute cette soupe).
    Je me répète (ou alors c'était dans l'autre post) mais un des intérêts principal est de pouvoir manipuler des objets fonctionnels et pas des tables.
    Bien utilisé, on a une approche très proche des triggers pour les contrôles (par callback) à la différence près (tout de même) en faveur du SGBDR que si on utilise un autre vecteur d'accès aux données, on perd la centralisation et l'intégrité des contrôles.

  5. #45
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 254
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 254
    Points : 1 240
    Points
    1 240

    Par défaut

    Mouais bon, je quitte la discussion : je vois le forum dans lequel mes posts ont été transférés, je ne risque pas de voir des personnes un peu plus ouvertes d'esprit à ce qui existe hors ORM...

  6. #46
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    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 698
    Points : 6 227
    Points
    6 227

    Par défaut

    Citation Envoyé par brice01 Voir le message
    Finalement, l'utilisation d'ORM c'est un peu choisir Windev comme outil de dev !
    Pas une ligne de code (ou presque), pas de code SQL (commande hlit...).
    Où est donc l'intérêt d'utiliser Java ?
    Non, c'est une affirmation fausse. Les ORM ont vraiment pas grand chose à voir avec les facilités que vous propose windev pour l'accès à ses propres outils de bases de données hyper file.
    Quant à l'intérêt d'utiliser java, prenez donc la peine de comparer ce que vous pouvez faire avec un ORM du style hibernate et ce que vous pouvez faire avec les ordres H** de windev, à la fois en terme de performance et de fonctionnalités et vous serez fixé.

    J'utilise Windev et je code mes requêtes SQL.
    J'ai essayé avec les ordres hlit... hajoute ... et question performance les requêtes SQL sont nettement plus performantes.
    La raison de ceci est qu'on ne travaille pas avec une base de données client-serveur de la même manière qu'avec un fichier monoposte en accès séquentiel. Vous pouvez affirmer que les ordres HLitXXX de windev sont très limitées, ne supportent pas les jointures et sont peu adaptés à la récupération de lots de données.
    Les mappings d'un ORM quant à eux peuvent générer les mêmes requêtes que vous écririez à la main, avec des jointures, des conditions, des sous-requête, bref du pur SQL que vous pouvez monitorer.

    Il faut bien entendu maitriser le SQL.
    En écrivant du code SQL respectant le norme SQL (la vrai, celle qui est respecté par la majorité des SGDB), on peut s'en sortir sans réécrire du code SQL si on change de SGBD.
    Si vous ne faites que des manipulations basiques oui, sinon les adaptations sont vite nécessaires. Surtout avec les dates comme ça a été cité, l'éventuelle absence de type booléen propre, ou les clefs primaires auto-incrémentées. Et quand on parle de programmation sur serveur (souvent utile), là on oublie la portabilité.


    Citation Envoyé par ego
    Pour ceux qui restent collé à leur SQL, vous vous trimballez, si vous faites du Java, avec vos ResultSet dans toute l'application ?
    Non nous avons des outils qui permettent de transformer des resultsets en POJO java fortement typés. Les mappings sont juste un élément de l'ORM que proposent égalements les mappers.
    Personnellement j'ai arrêté de croire qu'on pouvait bosser dans un monde merveillleux full OO en faisant semblant que c'est pas une base de données qui est derrière.

    Citation Envoyé par ego
    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.
    Il est parfois très judicieux lorsque vous calculez des statistiques lourdes, le genre qui vous oblige à appliquer un petit traitement à chaque ligne d'un resultset qui lui aussi nécessite une requête individuelle, de placer ça coté serveur afin de tirer partie des tables temporaires et/ou d'éviter 50'000 aller-retours entre le poste client et la base de données, en comptant l'overhead induit par la conversion du resultset en quelque chose d'utilisable dans votre technologie.

    Vous pouvez partir de l'idée que toutes les opérations sur le résultat d'un SELECT dans lequel chaque ligne nécessite une requête individuelle gagnent énormément à être faits coté serveur.
    Ils vous économisent les allers-retours réseau et permettent à vos transactions de durer moins longtemps en cas d'UPDATE.

    Citation Envoyé par dingoth
    Mouais bon, je quitte la discussion : je vois le forum dans lequel mes posts ont été transférés, je ne risque pas de voir des personnes un peu plus ouvertes d'esprit à ce qui existe hors ORM..
    Ben si : moi.
    Je n'ai pas non plus le sentiment qu'un ORM qui fait plein de magie est la solution parfaite, toutefois je ne suis pas contre un bon mapper.

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Citation Envoyé par _skip Voir le message
    Ben si : moi.
    Je n'ai pas non plus le sentiment qu'un ORM qui fait plein de magie est la solution parfaite, toutefois je ne suis pas contre un bon mapper.
    Moi aussi, je n'arrête pas de dire qu'il n'y a pas 1 bon outil et les autres mauvais, c'est une question de contexte et d'application...

  8. #48
    Membre du Club
    Inscrit en
    décembre 2004
    Messages
    88
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 88
    Points : 45
    Points
    45

    Par défaut

    La raison de ceci est qu'on ne travaille pas avec une base de données client-serveur de la même manière qu'avec un fichier monoposte en accès séquentiel. Vous pouvez affirmer que les ordres HLitXXX de windev sont très limitées, ne supportent pas les jointures et sont peu adaptés à la récupération de lots de données.
    Les mappings d'un ORM quant à eux peuvent générer les mêmes requêtes que vous écririez à la main, avec des jointures, des conditions, des sous-requête, bref du pur SQL que vous pouvez monitorer.
    Windev a évolué depuis la version 8 : Il fait du client-seveur. Mais là n'est pas la question. Windev fait du multi base sans changer le code source.

    Ce que je voulais dire, c'est que à la manière des ORM windev masque et simplifie la persistance des données et ce fonctionnement peut amener à des performances amoindrie.

    Je ne juge pas hibernate, ibatis ou tout autre ORM (j'ai jamais essayer .. à tort peut être) etje suis à 100% pour l'ORM pour faire du CRUD (mono-table) et seulement pour le CRUD.
    A partir du moment, où la requête est plus complexe (genre sous requêtes....) je ne suis pas sur que les ORM savent le gérer.
    De plus pour que le client serveur soit le plus performant possible il faut éviter les aller retour avec le serveur (requete avec sous requetes...).

  9. #49
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Mouais bon, je quitte la discussion : je vois le forum dans lequel mes posts ont été transférés, je ne risque pas de voir des personnes un peu plus ouvertes d'esprit à ce qui existe hors ORM...
    On ne dis pas cela. On essaye juste de vous convaincre que les ORM ne sont pas aussi mauvais que certains le pense et que, selon moi, le débat ne devrait pas se situer là ou il a été amené = les performances et la pseudo-négation du SQL.
    Encore une fois, il s'agit avant tout de conserver une manipulation homogène des concepts objets côté code. Il n'en reste pas moins important de savoir écrire des requêtes "SQL" sauf qu'on le fait avec un langage qui utilise plutôt le noms des attributs des classes et non leur correspondance en base (les colonnes). Une requête mal foutue en HQL (cas d'Hibernate), sera mal foutue en une fois traduite en SQL.
    Il s'agit donc d'une facilité c'est tout.
    Le seul problème de faire du SQL "natif" et qu'on est obligé ensuite de transférer les ResultSet dans les objets. C'est franchement inutile quand on a un framework qui le fait pour nous. Oui vous pouvez avoir mis en place des solutions maison qui fonctionnent bien mais comme d'habitude en informatique, pourquoi ré-inventer la roue (l'histoire des mapper peu tout à fait être suffisant dans bien des cas).
    Pour faire de la communication réseaux, dans la majorité des cas, je suppose que vous ne faite pas de la manipulation de sockets avec read/write, vous utilisez des protocoles/frameworks de plus haut niveau et vous avez raisons dans 99% des cas. Eh bien avec les ORM c'est un peu pareil.

  10. #50
    Membre expérimenté Avatar de Arkhena
    Inscrit en
    décembre 2006
    Messages
    480
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 480
    Points : 558
    Points
    558

    Par défaut

    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
    A bove ante, ab asino retro, a stulto undique caveto

  11. #51
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    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 698
    Points : 6 227
    Points
    6 227

    Par défaut

    Citation Envoyé par brice01 Voir le message
    Windev a évolué depuis la version 8 : Il fait du client-seveur. Mais là n'est pas la question. Windev fait du multi base sans changer le code source.
    Je sais qu'il existe une version client serveur, je me suis assez battu avec. L'aspect multi-base concerne les ordres H* et les bindings db-fenetre, et encore c'est si vous voulez bien acheter les accès natifs. Vous verrez toutefois que changer de base aura un impact sur votre schéma de données, même si une partie des changements est encapsulée par les drivers PCSOFT, ce n'est pas trivial et ça ne concerne pas les requêtes écrites à la main.

    Vous pourriez aussi dire qu'on peut faire du multi base via OLEDB ou ODBC, mais là aussi hors de la théorie ça pose vite des soucis.

    Ce que je voulais dire, c'est que à la manière des ORM windev masque et simplifie la persistance des données et ce fonctionnement peut amener à des performances amoindrie.

    Je ne juge pas hibernate, ibatis ou tout autre ORM (j'ai jamais essayer .. à tort peut être) etje suis à 100% pour l'ORM pour faire du CRUD (mono-table) et seulement pour le CRUD.
    A partir du moment, où la requête est plus complexe (genre sous requêtes....) je ne suis pas sur que les ORM savent le gérer.
    De plus pour que le client serveur soit le plus performant possible il faut éviter les aller retour avec le serveur (requete avec sous requetes...).
    Vous sous-estimez totalement les ORM, les sous-requêtes, les jointures conditionnelles et le chargement efficace de graphes d'objets sont pris en charge... en générant simplement du SQL dynamiquement.

  12. #52
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    Citation Envoyé par Arkhena Voir le message
    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
    Sur cet aspect, je suis 100% d'accord avec toi.
    Mais ceci est vraiment un problème d'éducation à la base (c'est le cas de le dire).
    Il est totalement clair que la conception de la base EST LE NERF DE LA GUERRE, avec aussi son mode d'utilisation par l'application.
    De ma modeste expérience, les problèmes de performance dans les applications sont bien souvent (je ne veux pas donner de chiffre mais je pencherai avec quelque chose de très gros !!) liés à la conception de la base et aux requêtes mal foutues. Ce n'est pas une garantie, je vous l'accord, mais je suis "assez vieux" dans l'informatique, j'ai commencé par du Pro*C avec Oracle dans le code C donc le SQL "natif", j'en ai fait pas mal.
    Mais pour autant, je trouve que les ORM sont vraiment une très bonne solution. Ca ne veut pas dire qu'il faut mettre les DBA à la poubelle et qu'il ne faut pas savoir concevoir une base (tables, vues, indexes, tablespaces, répartition disque,...)

  13. #53
    Membre actif
    Profil pro Benoit Rocco
    Inscrit en
    décembre 2009
    Messages
    88
    Détails du profil
    Informations personnelles :
    Nom : Benoit Rocco
    Âge : 34
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2009
    Messages : 88
    Points : 189
    Points
    189

    Par défaut

    Citation Envoyé par GLDavid Voir le message
    Hello

    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 ?

    @++
    De toute manière si on souhaite faire les choses correctement il faut développer une couche d'abstraction pour dissocier l'accès aux données de l'interface. En général ca revient en gros à écrire une classe pour chaque table avec une propriété pour chaque champ. Alors si un orm le fait à ma place, je suis preneur, quitte à faire le ménage après coup en supprimant les classes dont je n'ai pas l'utilité. Il me semble que ca peut apporter un bon gain en temps de développement mais je n'ai encore jamais utilisé ce genre d'outils, pour l'instant j'utilise encore de bonnes vieilles procédures stockées

  14. #54
    Membre expérimenté Avatar de NicoL__
    Homme Profil pro Nicolas
    Inscrit en
    janvier 2011
    Messages
    399
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas
    Localisation : France

    Informations forums :
    Inscription : janvier 2011
    Messages : 399
    Points : 548
    Points
    548

    Par défaut

    Donc à la réponse : Comment sont perçus les outils de mapping Objet /Relationnel (JPA, Hibernate, etc.) par vos DBA ? On peut dire que les DBA réagissent mal !
    Si on se tourne du coté des éditeurs et autre on remarquera que l'ORM a pris une grand place : Microsoft met en avant Entity Framework et en 2010 ne parle plus trop du bienfait des procsock et JPA est là pour unifier tout le monde java. Donc l'ORM monte en puissance.
    Et puis JPA est portable sur beaucoup d'implémentation donc beaucoup de base (y a des limitations potentielles) et même sur des bases NoSql (là y a plus de DBA pour ronchonner) le genre de techno poussée par google.
    L'ORM permet des gains de productivité du développeur au détriment d'un optimisation fine et des gain de performance. Or on compense la performance avec des serveurs de plus en plus puissants. Alors que le développeur il coûte toujours plus cher...

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •