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 2 sur 3 PremièrePremière 123 DernièreDernière
Affichage des résultats 21 à 40 sur 54
  1. #21
    ego
    ego est déconnecté
    Rédacteur

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

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 853
    Points : 3 182
    Points
    3 182

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Voici la référence intégrale de l'article postée sur le monde informatique, que je dois mettre sous developpez avec quelques éléments supplémentaires :
    http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

    A +
    eh ton "pote" d'Oracle il est allé expliqué sa théorie à ses collègues qui développent des progiciels ?
    Ils font comment ? Ils codent tout dans des proc stockées et ont un code pour Oracle, un pour SQL Server, un pour DB2, ....
    Même question côté SAP et autres BusinessObject, .....

    C'est vraiment pas sérieux, sincèrement

  2. #22
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 563
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 563
    Points : 30 071
    Points
    30 071

    Par défaut

    Citation Envoyé par ego Voir le message
    eh ton "pote" d'Oracle il est allé expliqué sa théorie à ses collègues qui développent des progiciels ?
    Ils font comment ? Ils codent tout dans des proc stockées et ont un code pour Oracle, un pour SQL Server, un pour DB2, ....
    Même question côté SAP et autres BusinessObject, .....

    C'est vraiment pas sérieux, sincèrement
    Avez vous déjà réellement développé une application multi base un peu sérieuse, genre ERP par exemple ?
    Il n'existe aucune requête même parmi les plus simples qui soit intéropérable entre les différents SGBDR....
    Penser que l'ORM gérera la chose est un non sens.....

    Mes nombreux audits m'ont montré qu'en tentant de faire cela, les éditeurs nivelaient le système tellement vers le bas que plus aucune montée en charge n'était possible !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 688
    Points : 7 093
    Points
    7 093

    Par défaut

    Citation Envoyé par ego Voir le message
    Au risque de ne pas t'avoir compris, je crois que c'est toi qui n'a pas compris ma remarque. Je ne suis justement pas attaché au passé et je pense que ceux qui sont contre les ORM sont parfois des gens attachés au passé, justement.

    Donc vive l'avenir !!
    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

  4. #24
    Expert Confirmé
    Inscrit en
    août 2008
    Messages
    2 173
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 2 173
    Points : 3 999
    Points
    3 999

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    Je reste convaincu que d'un point de vue performance, la procédure stockée sera largement plus performante qu'une suite de mise à jour pilotées par l'application...
    Pour une succession d'update unitaire certainement, mais définitivement il vaut mieux une requête générée répondant entièrement à la question qu'une horrible procédure stockée pensée exclusivement d'un point de vue procédural.

    Citation Envoyé par OButterlin Voir le message
    On passe d'une base de données Oracle à une DB2 ou MySQL sans l'ombre d'une modification.
    Syntaxiquement elles ont leurs spécificités certes (au grand dam de sqlpro )
    Cependant bien plus important, l'implémentation transactionnelle des éditeurs est différente.
    Comment les outils de mapping gèrent ils ces spécificités ? Des liens vers de la doc sont bien venus pour ma culture personnelle.
    Pour moi l'indépendance des bases est parfois un réel besoin client, mais le plus souvent juste une commodité pour les éditeurs de logiciels ou d'applications dont le client n'a que faire.
    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 ?

    Citation Envoyé par ego Voir le message
    mais franchement, on ne fait que rarement des requêtes compliquées quand on navigue dans un modèle objet.
    C'est certainement la dessus que les points de vue divergent le plus, et c'est applicable aux procédures stockées.
    Pour moi, c'est une seule requête (ou au max très peu) pour répondre à une question (généralement complexe), et pas une multitude de requêtes simplistes dans des boucles.

  5. #25
    Expert Confirmé Sénior
    Avatar de Alain Defrance
    Homme Profil pro Alain DEFRANCE
    Project Lead
    Inscrit en
    août 2007
    Messages
    1 994
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain DEFRANCE
    Âge : 27
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Project Lead

    Informations forums :
    Inscription : août 2007
    Messages : 1 994
    Points : 4 055
    Points
    4 055

    Par défaut

    Citation Envoyé par ego Voir le message
    Mais rien dans tout cela ne milite contre les ORM !
    Comme je l'ai mentionné, il ne s'agit pas d'accès génériques mais de facilité d'écriture de la requête.
    Si pour un besoin précis on veut ne remonter que partiellement un objet stocké dans une table, par exemple, on peut écrire un truc du genre :

    Code :
    select new ClientPartiel(nom,prenom,date naissance) from Client where ....
    Sachant que ce qui est décrit dans le fichier de mapping est la classe Client "totale".
    Bref, les ORM sont très très ouverts et permettent, quand on sait s'en servir (mais c'est comme tout, hein !?), de faire ce qui est le plus adapté.
    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.

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 688
    Points : 7 093
    Points
    7 093

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

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 688
    Points : 7 093
    Points
    7 093

    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

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

    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.

  9. #29
    Membre Expert Avatar de davcha
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 1 257
    Points : 1 399
    Points
    1 399

    Par défaut

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

  10. #30
    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 382
    Points
    1 382

    Par défaut

    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.

  11. #31
    Membre habitué
    Profil pro Yannick Majoros
    Inscrit en
    janvier 2007
    Messages
    108
    Détails du profil
    Informations personnelles :
    Nom : Yannick Majoros
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2007
    Messages : 108
    Points : 139
    Points
    139

    Par défaut

    Citation Envoyé par GLDavid Voir le message
    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 ?
    @++
    C'est un abstraction, c'est un fait, même si ce n'est pas la dernière couche. En final, ce sera bien du sql qui sera généré, ce n'est pas "un autre langage". Bien sûr, il y a plus de classes dans les applications, mais elles ne grossissent pas nécessairement. Elles sont simplement mieux découpées et on mélange moins facilement la persistance et le métier, avec tous les avantages liés. Les outils de développement modernes permettent de générer tout ça très rapidement, ce n'est pas nécessairement plus difficile à maintenir ("grossir méchamment" ?), au contraire. Mais il faut une certaine expérience de développement pour voir les avantages de cette abstraction supplémentaire.

  12. #32
    Membre Expert

    Homme Profil pro Chris Camel
    Architecte de système d'information
    Inscrit en
    novembre 2006
    Messages
    1 247
    Détails du profil
    Informations personnelles :
    Nom : Homme Chris Camel
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 247
    Points : 1 813
    Points
    1 813

    Par défaut

    Citation Envoyé par dingoth Voir le message
    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.

  13. #33
    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 382
    Points
    1 382

    Par défaut

    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 ?

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

    Par défaut

    Citation Envoyé par dingoth Voir le message
    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.

  15. #35
    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 382
    Points
    1 382

    Par défaut

    Citation Envoyé par _skip Voir le message
    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.

    Citation Envoyé par _skip Voir le message
    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.

    Citation Envoyé par _skip Voir le message
    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.

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 688
    Points : 7 093
    Points
    7 093

    Par défaut

    Citation Envoyé par dingoth Voir le message
    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.
    Le jour où il se mettront d'accord sur un langage et des fonctionnalités 100% communs, pourquoi pas... il ne restera plus alors que le problème des paramètres à passer à la store proc pour remplir sa fonction (quand on ajoute des colonnes en cours de route par exemple)...

    En attendant, l'ORM a de beaux jours devant lui, et sûrement pas parce qu'il est mauvais et qu'on est tous des andouilles à suivre les modes

    Utiliser un ORM juste pour éviter de coder soit même des classes typées "Entity" en JDBC est déjà bien, même si c'est très limitant.
    Je préfère considéré l'ORM comme un super outil qui me permet de causer fonctionnel plutôt que table et laisse la "plomberie" (pour citer l'expression de _skip) au moteur (avec des possibilités de spécialisations par SGBDR via les "dialect").

    Pour résumer, sans contraintes fortes de performances, je choisis l'ORM plutôt 2x qu'une.

  17. #37
    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 382
    Points
    1 382

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    [...] et qu'on est tous des andouilles à suivre les modes
    Je ne dis pas cela et suis à mille lieues de le penser. L'expérience que j'en ai ne me convainc pas. Si sur 1000 développeurs, 800 utilisent un ORM, c'est qu'il a ses qualités. Je fais partie du reste qui en demande davantage.

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 688
    Points : 7 093
    Points
    7 093

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Je ne dis pas cela et suis à mille lieues de le penser. L'expérience que j'en ai ne me convainc pas. Si sur 1000 développeurs, 800 utilisent un ORM, c'est qu'il a ses qualités. Je fais partie du reste qui en demande davantage.
    Je te rassure, je ne pensais pas à toi mais à un pro du sql

  19. #39
    ego
    ego est déconnecté
    Rédacteur

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

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 853
    Points : 3 182
    Points
    3 182

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    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

  20. #40
    ego
    ego est déconnecté
    Rédacteur

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

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 853
    Points : 3 182
    Points
    3 182

    Par défaut

    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.

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
  •