+ Répondre à la discussion Actualité déjà publiée
Page 9 sur 11 PremièrePremière ... 567891011 DernièreDernière
  1. #161
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    C'est d'un simplicité enfantine.
    Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
    Il est alors d'une simplicité biblique de les tester unitairement...

    A +
    1: je croyais que les procédures stockées et plutôt difficiles à porter d'un SGBD à un autre voire d'une version d'un SGBD à une autre.

    2 : avec HIBERNATE et JAVA on ne code le CRUD qu'une fois avec un DAO générique :on utilise des éléments qui font la force de JAVA (il a des mécanismes analogues dans d'autres langages objets) : héritage et générics => moins de code à écrire qu'en PL SQL sur ce cas précis.

    3 : un test unitaire doit permettre de tester le bon fonctionnement d'un bout de code en isolation des autres. En JAVA c'est possible avec les mock (avec les librairies de mock on a peu de chose à écrire à la main). en PL SQL celà ne me semble pas possible ou difficilement.
    ex : une procédure A fait un traitement et appelle des traitements faits dans des procédures B et C. Comment tester A sans utiliser B ni C?

    4 : l'ensemble des tests unitaires doivent tourner rapidement.
    en JAVA 80/90% des tests unitaires seront sur la couche métier et la BDD ne sera pas sollicitée (on mocke les DAO) et les tests unitaires restant porteront sur les DAO : pour ces cas, on remplit une BDD de test avec un jeu de données de test puis on joue le test unitaire puis on remet la BDD de test dans son état initial. On procède ainsi afin de respecter une autre règle sur les tests unitaires : leur indépendance entre eux.
    Au final l'ensemble des tests unitaires passeront très vite.
    en PL SQL il faudra taper dans la BDD de test pour tous les tests (et après chaque test la remettre dans l'état initial) => l'ensemble des tests unitaires passeront beaucoup plus lentement.


    cordialement
    loïc midy

  2. #162
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut remarques article : Darwinisme et informatique : les ORM...

    bonjour,

    voici plusieurs remarques sur l'article : Darwinisme et informatique : les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ?

    Citation article :
    Il s'ensuit une analyse des retours d'expériences menées par l'auteur en comparant les développements conçus par l'approche traditionnelle et celle du concept de développement
    épais côté bases de données.
    Et le constat fait froid dans le dos...
    o réduction par un facteur 3 à 4 des lignes de code client, donc réduction potentielle par
    ce même facteur des bugs non encore découverts;
    o division par un facteur 10 à 100 des temps de réponse du système;
    o réduction par un facteur 2 à 3 du temps global de développement.


    L'article cité (http://www.dulcian.com/Articles/Thic...ited_final.htm ) fait des comparaisons biaisées. Notamment l'auteur compare des développement dits traditionnels aux développements base de données épaisse MAIS dans les 2 premiers cas cités sont biaisés.
    Exemple 1 : the most significant performance problems [en développement traditionnel] were due to poorly coded SQL
    Exemple 2 : Performance was poor, mainly because of excessive round trips and unnecessary full tree refreshes. [en développement traditionnel]
    L'auteur reconnaît lui même le biais dans ses analyses !!!: It is somewhat unfair to apply the thick database approach to existing, poorly performing systems since this may only highlight its possible effects on projects that would particularly benefit from using the approach. Also, it is always easier to build something better the second time.
    Il donne alors un dernier exemple censé ne pas être biaisé mais il donne peu d'informations.

    Citation article :
    Malgré tous les caches qu’on leur met, les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client. La phrase s'appuie sur 2 référence. La première référence compare HIBERNATE versus du code JDBC fait à la main et conclue que le JDBC est bien meilleur.
    Dans le livre «*java persistance with hibernate*» les auteurs (les créateurs d'hibernate) disent : The really interesting question is what happens when we consider time and budget constraints?
    Given a persistence task, many optimizations are possible. Some (such as query hints) are much easier to achieve with hand-coded SQL/JDBC. Most optimizations, however, are much easier to achieve with automated ORM. In a project with time constraints, hand-coded persistence usually allows you to make some optimizations. Hibernate allows many more optimizations to be used all the time. Furthermore, automated persistence improves developer productivity so much that you can spend more time hand-optimizing the few remaining bottlenecks.
    Ailleurs ils disent : the main purpose of up to 30 percent of the Java application code written is to handle the tedious SQL/JDBC and manual bridging of the object/relational paradigm mismatch
    Sur un projet réel développé récemment dans mon service, hibernate a été utilisé avec HQL pour plus de 95% des requêtes. Pour les 5% restantes il a fallu passer par SQL pour des questions d'optimisation. Au final, le code est suffisamment optimisé pour nos besoins et le temps de développement aurait été plus long si on avait tout fait en JDBC/SQL.


    Citation article :
    Quant à l’argument qui consiste à dire que la maintenabilité du code d’un langage client est bien plus simple que du SQL, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire.
    La comparaison n'a pas vraiment de sens. Si je me réfère à JAVA une bonne partie du code peut être généré par l'IDE (ex: getters et setters) et ne demandent aucune maintenance. Il faudrait enlever ces lignes de codes pour comparer proprement.
    De plus la maintenabilité ne dépend pas uniquement du nombre de lignes de code. Par exemple, la modularité du code joue également tout comme la qualité de la documentation (la JAVADOC c'est très bien et c'est dans le code donc syncronisé avec. Existe t'il une aussi bonne façon de faire de la doc en PL SQL?)

    cordialement
    loïc midy

  3. #163
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    C'est drôle combien certains pensent toujours que le terme "portabilité" signifie une seule techno, mais 10 SGBDR, alors que l'inverse non.


    Mettons une seule base de données, mais avec une interface de gestion en HTML sur serveur d'app Java, une interface d'utilisation en C++ et une troisième en PHP pour les visiteurs occasionnels.

    Vous aimeriez avoir à recoder le tout à chaque fois dans chaque langage ? Où placer le métier dans ce cas ? Il faut le coder 3 fois ou une seule fois dans la base de données ? Où est le véritable gain de temps ?

    Ce genre d'architecture n'est pas si rare (et ce n'est pas parce que vous ne l'avez pas rencontré qu'elle n'existe pas).

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

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

    Par défaut

    Ou alors, tu codes un service qui tape dans la base de donnée et qui fournit ce qu'il faut aux différents satellites de ton truc.

  5. #165
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par dingoth Voir le message
    C'est drôle combien certains pensent toujours que le terme "portabilité" signifie une seule techno, mais 10 SGBDR, alors que l'inverse non.


    Mettons une seule base de données, mais avec une interface de gestion en HTML sur serveur d'app Java, une interface d'utilisation en C++ et une troisième en PHP pour les visiteurs occasionnels.

    Vous aimeriez avoir à recoder le tout à chaque fois dans chaque langage ? Où placer le métier dans ce cas ? Il faut le coder 3 fois ou une seule fois dans la base de données ? Où est le véritable gain de temps ?

    Ce genre d'architecture n'est pas si rare (et ce n'est pas parce que vous ne l'avez pas rencontré qu'elle n'existe pas).
    Oui, c'est même plutôt courant. Après cela dépend aussi de ce que tu fais.
    Imaginons que tu vendes un ERP quelconque, une apppli de gestion :
    - Tu vas chez X, tu es 100%, sauf l'IT qui homologue "DB2 sous linux"
    - Tu vas chez Y, tu es 100%, sauf l'IT qui homologue "SQL 2005 sous 2008 R2"

    Moi je crois que c'est surtout l'aspect "systèmatique" du recours aux sgbd qui a créé ce besoin d'indépendance, pour pouvoir créer des offres qui s'intégrent aussi dans les systèmes clients. La situation que tu décris est le vision interne de la donnée, la situation de l'indépendance est la vision externe.

    En ce moment je regarde des moteurs nosql par ex, et pour des processus complexe ou des archi multi-tenancy, c'est très intéressant, en tous cas beuacoup plus performant et adapté que des modéles relationnels.

    Il y a toujours un cout d'exploitation. Sa rationalisation ce n'est pas de faire du prosélitisme "tout en SQL Server" comme le fait SQL Pro. Le monde est diversité.

    Il s'agit de trouver l'architecture la plus performante au regard d'un contexte et pas que du point de vue de la donnée.
    Une architecture ouverte hétérogéne ? Oui ! Si dans son environnement chaque compêtence est présente et assumée, oui ça présente du sens.
    Une architecture J2EE dans une boite où tout est VB6 + Access ? Non ! Ce n'est plus une question d'architecture, mais une logique de conduite du changement.

    Et dans la culture Française (c'est un constat) nous sommes très résistants au changement. Ce qui a souvent tendance à être un critére fort d'échec.

  6. #166
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    1 250
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 1 250
    Points : 1 085
    Points
    1 085

    Par défaut

    est-il bien d'utiliser un ORM quand N applications accedent à une BD?
    ne factorise-t-on pas le code en utilisant des stored procedures?
    j'avais aussi compris qu'un ORM n'aimait pas qu'on modifie la DB sans lui dire... (caches pas mis a jour)
    aussi si le code est dans les N applications, n'est-il pas interessant de modifier une seul fois le code coté database, sans que les appli soient touchés?

  7. #167
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 481
    Points
    5 481

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    est-il bien d'utiliser un ORM quand N applications accedent à une BD?
    ne factorise-t-on pas le code en utilisant des stored procedures?
    j'avais aussi compris qu'un ORM n'aimait pas qu'on modifie la DB sans lui dire... (caches pas mis a jour)
    aussi si le code est dans les N applications, n'est-il pas interessant de modifier une seul fois le code coté database, sans que les appli soient touchés?
    C'est plus une question d'architecture applicative que d'utiliser un ORM ou des procédures stockées. Dans une architecture N-tiers tu vas mettre toute l'utilisation de l'orm ou des procédures stockées dans ta couche application donc c'est tout aussi bien factorisé avec l'un qu'avec l'autre. Et si le code est partagé par N applications tu n'as qu'a modifier ta couche application (donc soit les procédures stockées soit l'utilisation ORM). Dans les 2 cas cela ne change rien.

    Pour ma part l'utilisation d'un ORM simplifie (quelque fois et uniquement pour ce que j'en ai vu avec linq parce que les autres...) et généralise l'écriture de requêtes. Et en simplifiant alors la maintenance est plus facile et comme la maintenance c'est 87% du temps que l'on passe sur un logiciel.
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  8. #168
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    est-il bien d'utiliser un ORM quand N applications accedent à une BD?
    ne factorise-t-on pas le code en utilisant des stored procedures?
    j'avais aussi compris qu'un ORM n'aimait pas qu'on modifie la DB sans lui dire... (caches pas mis a jour)
    aussi si le code est dans les N applications, n'est-il pas interessant de modifier une seul fois le code coté database, sans que les appli soient touchés?
    Là c'est une question différente : ça léve la question du SI vs une application.
    Pour éviter de faire cela, on a préconisé les architectures de service, de telles façon que toute application puisses accéder à des données sans justement révolutionner l'informatique en distribuant des transactions sur n applications.

    Quand la DB est un élément METIER central, il faut effectivement faire preuve de bon sens et raisonner en termes de services et utiliser des sp ou des éléments qui ne vont pas transformer un système d'information en un patchwork technologique.
    En outre, SP et ORM ne sont pas incompatibles ni exclusifs.

  9. #169
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    1 250
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 1 250
    Points : 1 085
    Points
    1 085

    Par défaut

    Comment font les ORM quand la database est modifié en dehors de leur controle? J'ai cru comprendre que ca n'aimait pas du tout ca, beaucoup de probleme avec les caches etc.

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

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

    Par défaut

    Ca dépend. Tu parles d'une modification des données ou de la structure ?

    Si la structure est modifiée c'est clair que c'est le bordel. Mais ça le serait également autrement (sauf à tout mettre derrière une facade view/procédures stockées, mais si tu modifies ta facade, tu as le même problème).

    Si tes données sont modifiées, ton ORM et ta base sont désynchronisés, et ça peut facilement devenir pénible à gérer.

  11. #171
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    Comment font les ORM quand la database est modifié en dehors de leur controle? J'ai cru comprendre que ca n'aimait pas du tout ca, beaucoup de probleme avec les caches etc.
    "Ils" ne font rien. D'une façon plus générale, c'est à déconseiller fortement.

  12. #172
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    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 859
    Points : 7 209
    Points
    7 209

    Par défaut

    En même temps on ne crée que rarement des caches sur des données susceptibles d'être modifiées depuis l'extérieur si l'on doit impérativement refléter les changements immédiatement.

    C'est pas une limitation d'un ORM, mais bel et bien du principe même d'un cache.

  13. #173
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    1 250
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 1 250
    Points : 1 085
    Points
    1 085

    Par défaut

    peut-on agir sur le cache? (je ne crois pas)
    peut-on interdire d'utiliser le cache sur une table precise? (je ne crois pas non plus)

    ensuite sur la modification de structure, j'avais compris que meme un champs rajouté faisait que l'ORM ne marchait plus. Vous confirmez?

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

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

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    ensuite sur la modification de structure, j'avais compris que meme un champs rajouté faisait que l'ORM ne marchait plus. Vous confirmez?
    Quand même pas non.

    Sauf si c'est un champ not null sans valeur par défaut.

  15. #175
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    peut-on agir sur le cache? (je ne crois pas)
    peut-on interdire d'utiliser le cache sur une table precise? (je ne crois pas non plus)

    ensuite sur la modification de structure, j'avais compris que meme un champs rajouté faisait que l'ORM ne marchait plus. Vous confirmez?
    De toutes les façons, le problème principal vient de la gestion des états et de la concurrence. Ce qui va se traduire par un dysfonctionnement majeur de l'ORM n'est que le reflet d'une défaillance bien plus grave qui est l'intégrité référentielle de la base.

    Les ORM sont tous différents donc il est difficile de généraliser un comportement, donc on ne peut rien confirmer ou infirmer. A l'identique sur les questions de cache.

    Ta question au final reléve plus de dire : faut-il préconiser une architecture client serveur hétérogène (A savoir n architectures clientes pour une seule et même db avec des accès concurrents) ? La réponse est simple et définitive : non.
    Si il y a un moment besoin de n clients accédant à la même donnée, là il devient nécessaire de se poser la question du service.

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

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

    Par défaut

    Précises, B.AF : n instances différentes du même client ou n clients différents.

  17. #177
    Expert confirmé
    Profil pro
    Inscrit en
    août 2006
    Messages
    3 200
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 3 200
    Points : 4 004
    Points
    4 004

    Par défaut

    peut-on agir sur le cache? (je ne crois pas)
    peut-on interdire d'utiliser le cache sur une table precise? (je ne crois pas non plus)
    Concernant Hibernate, le cache est paramétrable.
    Tu peux l'activer ou pas pour telle ou telle entité, donc table.

  18. #178
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par fr1man Voir le message
    Concernant Hibernate, le cache est paramétrable.
    Tu peux l'activer ou pas pour telle ou telle entité, donc table.
    A moitié faux. Tu ne peux pas manipuler celui qui sera le plus gênant dans ce cas et qui sera le cache de niveau 1, qui est en fait le registre des entités manipulées par la session actuelle.

    Il existe bien un cache de second niveau, mais qui lui ne sera qu'un problème supplémentaire.

  19. #179
    Expert confirmé
    Profil pro
    Inscrit en
    août 2006
    Messages
    3 200
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 3 200
    Points : 4 004
    Points
    4 004

    Par défaut

    Oui je parlais du cache de niveau 2, j'aurais du préciser.

    Quant à dire que son utilisation ne sera qu'un problème supplémentaire, faut pas pousser non plus.

  20. #180
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par fr1man Voir le message
    Oui je parlais du cache de niveau 2, j'aurais du préciser.

    Quant à dire que son utilisation ne sera qu'un problème supplémentaire, faut pas pousser non plus.
    Je ne sais pas quels caches tu utilises, mais l'invalidation ou la synchronisation sont des notions importantes.

    Si tu utilises un cache x (prevalence, ou memcache par ex). Tu te dis à juste titre : j'ai une entité dont j'ai fréquemment besoin. Tu décides donc d'initialiser un pool d'objet d'utiliser le cache pour limiter les hits db. Ce qui semble être une bonne idée.
    Pendant ce temps, une application omega vient modifier en raw sql les données utilisée pour générer les entités en cache.
    Ces modifications ne passant par ta couche d'accès aux données, tu recevras les données que tu as initialement cachées, qui seront incohérentes avec les données physiquement en base.
    A moins de construire une usine à gaz de listener avec certains moteurs de caches, tu cours droit à la catastrophe car tu induis alors une faille dans ta conception logicielle.

Discussions similaires

  1. Les IDE sont-ils dangereux pour les développeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 85
    Dernier message: 13/05/2014, 11h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 19h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 08h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 08h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 23/11/2008, 23h13

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