+ Répondre à la discussion Actualité déjà publiée
Page 10 sur 11 PremièrePremière ... 67891011 DernièreDernière
  1. #181
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    1 245
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 1 245
    Points : 1 084
    Points
    1 084

    Par défaut

    Citation Envoyé par B.AF Voir le message
    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.
    moi je dirais qu'une DB est faite pour plusieurs clients,
    donc je me poserais la question en premier lieu, et j'essaierais de normaliser l'acces aux données par des stored procedures.

  2. #182
    Membre expert
    Profil pro
    Inscrit en
    août 2006
    Messages
    3 192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 3 192
    Points : 3 986
    Points
    3 986

    Par défaut

    @B.AF

    Je suis bien conscient de tout ça, ce n'est pas pour autant que ce n'est pas utilisable.
    Et puis si c'est un problème pour l'architecture visée et bien tu ne te sers pas de ce cache de niveau 2 et tu te contentes de celui de niveau 1.

  3. #183
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par fr1man Voir le message
    @B.AF

    Je suis bien conscient de tout ça, ce n'est pas pour autant que ce n'est pas utilisable.
    Et puis si c'est un problème pour l'architecture visée et bien tu ne te sers pas de ce cache de niveau 2 et tu te contentes de celui de niveau 1.
    Excuses moi mais c'est un peu vert comme architecture. Tu ne peux pas utiliser un outil par la contrainte. Même le cache de niveau supporte les risques d'intégrité, les problèmes de versioning.

    On ne peut pas concevoir un dal qui passe son temps à se préoccuper de ce que les autres dal accédant aux mêmes données risquent de faire ou de ne pas faire.

    L'ORM n'est pas la silver bullet.

  4. #184
    Membre expérimenté
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 103
    Points : 1 523
    Points
    1 523

    Par défaut

    epsilon68 je te déconseille fortement de laisser à ton SGBDR le loisir de gérer lui même l'accès concurrentiel, à moins que tu ne souhaite avoir du côté de tes n instances clientes, des bugs pour le moins incongrus et pas toujours très facile à repérer, et ce même avec des transactions en niveau d'isolation maximum (sérialisation)

    l'isolation maximum, risque de créer des cas de famines, et un niveau moindre des incohérences de données, et je ne te parle même pas d'accès désordonnés à des ressources pouvant conduire à des étreintes mortelles.
    certes les SGBDR détecte cela très bien... ce n'est parce qu'ils le détectent et que selon le SGBDR ils font des choix pour le moins arbitraire, que c'est bien pour autant de laisser ce genre de cas se produire... et l'accès concurrentiel à une base de données, mène tôt ou tard à ce genre de dérive, car tu n'est pas obligatoirement maître de tous les accès.
    Si demain on doit accéder à ta base pour synchroniser les données avec un autre milieu, les risques de dead-locks et famines vont se multiplier encore plus... d'où la réponse cohérente de B.AF... il est préférable d'envisager une architecture de services.

    Après tout est question de grandeur... si ta 2 instances du même client, qui généralement ne travail même pas sur la même zone du domaine des données, alors oui... passer par des services, c'est un peu comme chasser le moustique au canon... mais sur des projets de plus grosses amplitude...

    B.AF toi qui a l'air de connaître... Entity Framework a pour chaque entité une option que l'on peut activer, qui est "accès concurrentiel"... à priori elle a pour effet, de désactiver un cache, mais est-ce comme dans Hibernate juste la désactivation d'un cache de niveau 2, ou EF ne possède pas 2 niveaux de caches ?

  5. #185
    Membre expert
    Profil pro
    Inscrit en
    août 2006
    Messages
    3 192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 3 192
    Points : 3 986
    Points
    3 986

    Par défaut

    Personne n'a dit que l'ORM était la silver bullet.

    Le cache de niveau 1 étant censé avoir une durée de vie courte, contrairement à celui de niveau 2, le risque d'avoir des données périmées est bien plus faible.

    Les problèmes d'intégrité et de versionning ne sont pas liés qu'aux ORM.

  6. #186
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Le problème n'est pas à la portée de l'ORM en fait ou d'une de ses fonctionnalités.

    Quant 5 socles, ORM ou pas, accèdent de façons concurrente et cloisonnée à la même base, si les transactions et l'intégrité ne sont pas posé au niveau de la db, le risque de dysfonctionnement est inévitable et garanti.

    Quand bien même je fais du short session dans une application, si pendant mon traitement une application lambda force la maj des données, j'aurai une stale state exception et ce sera normal.

    J'aurai plutôt tendance à dire qu'il faut plutôt dans ce cas raisonner sur des techno comme ADO.NET Data Services si on veut vraiment utiliser un ORM.

  7. #187
    Expert éminent
    Avatar de Michel Rotta
    Homme Profil pro
    Responsable d'exploitation informatique
    Inscrit en
    septembre 2005
    Messages
    4 927
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Responsable d'exploitation informatique
    Secteur : Distribution

    Informations forums :
    Inscription : septembre 2005
    Messages : 4 927
    Points : 8 303
    Points
    8 303

    Par défaut

    En fait, l'important est peut-être de savoir, avant d'écrire l'application si ce qui est important, c'est l'application ou la base de donnée.

    Je m'explique, dans le cadre le plus courant, ce qui est important, c'est l'application. Ici l'ORM va permettre (s'il est bien écris) d'avoir une indépendance entre l'application et la base de données, et d'utiliser le même code quelque soit la base de données choisie, au finale, pour l'application. Vois même, en fonction de l'évolution, de changer de base de données, sans pour autant avoir à retoucher le code. Au prix d'une petite perte de performance.

    Il arrive que les performances et la base de donnée soit plus importante que le développement, la couche ORM à alors moins d'intérêt, et pourrait, peut-être, être abandonné... Dans un cas pareil, l'utilisation intensive de procédures stockées pour la gestion et la récupération des données est assurément un plus important.

    Dans le cadre d'un accès à la base de données par deux (ou plus) applications différentes, il est évident qu'il faut considérer la deuxième option. Voir une troisième qui serait une couche intermédiaire d'accès et de vérification, mais les bases de données actuelles couvre, en générale, ces besoins.
    Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).

    • Pensez à valoriser les réponses pertinantes, cliquez sur le bouton vert +1 pour indiquer votre accord avec la solution proposée.
    • Pensez à utiliser la balise [code] pour afficher du code, elle est cachée sous le bouton [#] dans l'éditeur.
    • Une discussion est terminée ? Alors le bouton est votre ami !

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

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

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 282
    Points : 2 558
    Points
    2 558

    Par défaut

    Citation Envoyé par cinemania Voir le message
    epsilon68 je te déconseille fortement de laisser à ton SGBDR le loisir de gérer lui même l'accès concurrentiel ...
    C'est bien dommage car les SGBDR font ça très bien et de manière redoutablement efficace ...

    Les problèmes de gestion de la concurrence sont connus depuis longtemps et ont donné lieu à beaucoup de travaux théoriques dès les les années 70 avec des implémentations réussies même dans des SGBD "pré-relationnels".

    Je ne vois pas en quoi une architecture de service (c'est quoi d'ailleurs ?) peut apporter de neuf ou de magique sur ce sujet.

    Je parle bien sûr d'un SI un peu significatif, et pas d'une malheureuse application intranet avec 2 utilisateurs et qui a été développée par le stagiaire d'été qui passait par là ...

  9. #189
    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 655
    Points
    5 655

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Je ne vois pas en quoi une architecture de service (c'est quoi d'ailleurs ?) peut apporter de neuf ou de magique sur ce sujet.

    Je parle bien sûr d'un SI un peu significatif, et pas d'une malheureuse application intranet avec 2 utilisateurs et qui a été développée par le stagiaire d'été qui passait par là ...
    SOA(architecture orienté service). Vous ne connaissez pas rpc et les web service ?

    Il n'y a rien de magique non plus dans un SBGDR ou une procédure stockée.

    Mettre un composant informatique entre le client et un système de base de données est également un pattern d'architecture qui s'applique bien à SOA.
    " 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 ]

  10. #190
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Je ne vois pas en quoi une architecture de service (c'est quoi d'ailleurs ?) peut apporter de neuf ou de magique sur ce sujet.

    Je parle bien sûr d'un SI un peu significatif, et pas d'une malheureuse application intranet avec 2 utilisateurs et qui a été développée par le stagiaire d'été qui passait par là ...
    Justement les SI sont souvent composés d'une somme d'applications hétérogénes du fait de la taille, de la technologie, de l'utilité.
    Ce qui fait que fut une période ou l'informatique d'entreprise était à plus de 70% concernée par les problèmatiques d'intégration (qui n'a pas entendu le néologisme "transcodage").
    Une architecture de service serait une logique de bus où le SI est un composé de fonction métier. C'est à dire que le service encapsule les questions d'intégration et de technologie.
    Chaque service étant par définition interopérable avec les autres, cela facilite la création de processus verticaux par l'utilisation de points uniques.
    C'est très proche du principe du design pattern facade et c'est plutôt une bonne chose.
    C'est en tous cas un raisonnement plus fiable que d'avoir des cron qui font des ftp et qui lancent des korn shell qui eux même déclenchent du C++ qui appellent une sp de la base de donnée x.
    Ca ne réinvente pas la roue, c'est juste un raisonnement plus industriel et moins bidouille et surtout beaucoup plus maintenable.

  11. #191
    Membre régulier
    Profil pro
    Inscrit en
    mars 2004
    Messages
    98
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2004
    Messages : 98
    Points : 105
    Points
    105

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Allez, tout le monde switche vers Apache DbUtils !
    Ou vers MyBatis + un cache quelconque style memcached.

    Au final, d'après quelques expériences lues ici:

    - Hibernate à un coût non négligeable en perfs (ce que je corrobore avec des mesures extensives pour des opérations CRUD). MyBatis, a contrario, a un coût minimal / JDBC.

    - la génération auto de requêtes peut créer des requêtes lentes qu'il faut optimiser ensuite à la main, ce qui fait que l'avantage initial en terme de dev (on a vite un prototype qui fonctionne) est perdu par la suite en optimisation. Par contre, l'optimisation de requêtes nécessite des outils et/ou des connaissances que le développeur Java moyen n'ont pas. Un ORM comme Hibernate permet d'obtenir des requêtes correctement formées dans la plupart des cas.

    - il n'y a pas besoin de connaître SQL. Cet argument est un voeu pieux. Il n'est simplement pas possible de développer un soft basé sur un SGBD SQL sans connaitre un minimum de SQL, ne serait-ce que pour débugger. On a tjrs besoin de faire des requêtes à la main, requêtes qui sont d'ailleurs à peu près les mêmes que celles du programme.

    - l'ORM permet de s'affranchir des particularités du SGBD. SQLPro dit que c'est inexact. Je n'ai pas suffisamment d'expérience pour avoir mon avis la-dessus, mais ce qui me parait certains, c'est que les entreprises qui basent leurs gros devs sur une solution Oracle ne risquent pas de changer de SGBD de sitôt. Pour une banque ou une administration, par exemple, cet argument me parait donc relativement mineur. Mais pour d'autres applications, il est plus pertinent.

    Après, pour ce qui est du développement, vu qu'on utilise majoritairement des langages objet en entreprise (Java, C#), vouloir garder un modèle objet est loin d'être déconnant, bien que le mapping soit fastidieux à la main, mais relativement automatisable (ce que font Hibernate, MyBatis et d'autres).
    Le vrai avantage d'un ORM apparait, comme il a été rappelé, quand on part d'une base vierge et qu'on fait du MDA. On crée son modèle objet, et le schéma de base est créé en fonction. La modification du modèle, qui peut être importante dans les premières itérations du projet et/ou que les spécifications fonctionnelles ne sont pas fixées, est alors quasi instantanée, et on ne se retrouve pas avec des bugs de mapping en permanence. Mais quand il s'agit de mapper un schéma déjà existant, un outil comme Hibernate est probablement une perte de temps plus qu'autre chose (Mybatis est plus adapté).

    Il se trouve que les langages fonctionnels sont probablement plus adaptés à la manipulation du SQL que le Java. Peut-être qu'avec l'adoption de paradigmes fonctionnels, les ORM disparaitront.

  12. #192
    Membre à l'essai
    Profil pro
    Inscrit en
    avril 2006
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2006
    Messages : 14
    Points : 21
    Points
    21

    Par défaut

    Citation Envoyé par Patriarch24 Voir le message
    ... s'ils étaient si catastrophiques que cela [...], ils ne seraient plus beaucoup utilisés et soutenus depuis longtemps
    Le syndrome du "si ça passe à la télé, c'est forcément un bon produit"

  13. #193
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 858
    Points : 6 898
    Points
    6 898

    Par défaut

    le syndrome de la confiance des experts ...

    EDIT : ou celui de déterrage de topic.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  14. #194
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 611
    Points : 38 491
    Points
    38 491

    Par défaut

    Toujours les mêmes désespérantes idioties...

    Citation Envoyé par cinemania Voir le message
    ...je te déconseille fortement de laisser à ton SGBDR le loisir de gérer lui même l'accès concurrentiel, à moins que tu ne souhaite avoir du côté de tes n instances clientes, des bugs pour le moins incongrus et pas toujours très facile à repérer, et ce même avec des transactions en niveau d'isolation maximum (sérialisation)
    Un SGBDR ne choisit pas de lui même le niveau d'isolation. Il est par défaut à un niveau que le développeur doit monter en fonction de ses besoins et des traitements à faire... Problème : rare sont les développeurs qui savent réellement ce qu'est l’isolation et peu savent la modifier. Pire, un certain nombre d'ersatz de SGBDR comme MySQmerde ne permettent pas grand chose en cette matière, voir rien ! (pas de transactions dans MyISAM).
    Quand à piloter l’isolation au niveau du code c'est mathématiquement impossible. je m'amuse à le démontrer quotidiennement la chose dans toutes les formations que je donne !

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

  15. #195
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 611
    Points : 38 491
    Points
    38 491

    Par défaut

    Ca c'est aussi parfaitement stupide :
    Citation Envoyé par Michel Rotta Voir le message
    En fait, l'important est peut-être de savoir, avant d'écrire l'application si ce qui est important, c'est l'application ou la base de donnée.
    Expliquez moi un peu ce que vous pouvez faire avec votre programme mais sans les données ?

    Maintenant pouvez vous faire quelques chose avec les données sans votre programme ?

    la question est donc stupide. L'important dans le SI c'est TOUJOURS les données !

    malheureusement peu de gens en ont conscience hélas...

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

  16. #196
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 611
    Points : 38 491
    Points
    38 491

    Par défaut

    Oulala, beaucoup de bêtise et en plus on me prête des propos que je n'ai jamais dit !

    Citation Envoyé par el muchacho Voir le message
    Un ORM comme Hibernate permet d'obtenir des requêtes correctement formées dans la plupart des cas.
    Pour en avoir vu de multiples fois en audit, les requêtes pissées par Hibernate sont en général le summum du crétinisme... Exemple 185 requête avec WHERE toto = 245 puis WHERE toto = 851 etc, au lieu de WHERE toto IN (245, 851...) générant des round-trip en pagaille pendant une transaction... les verrous étant maintenant pendant tout ce process on constatait 99% du temps consacré au réseau pour 1% de réel traitement de la part du SGBDR !!! Bravo hibernate
    Parlons de la méthode de pagination d'Hibernate qui consiste pour chaque page à afficher de reparcourir toutes les données : Superbe !!!
    Parlons aussi des jointures spaghetti qu'Hibernate génère à outrance....
    Pour ma part en 15 ans d'audit, j'ai vu deux entreprises faire faillite à cause des mefaits d'Hibernate...


    - l'ORM permet de s'affranchir des particularités du SGBD. SQLPro dit que c'est inexact.
    je n'ai pas dit que c'était inexact.. j'ai dit que c'était utopique et d'ailleurs une même requête dans Hibernate provoque des résultats différents dans les différentes SGBDR, ne serait-ce qu'à cause de la gestion des collations...

    Le vrai avantage d'un ORM apparait, comme il a été rappelé, quand on part d'une base vierge et qu'on fait du MDA. On crée son modèle objet, et le schéma de base est créé en fonction. La modification du modèle, qui peut être importante dans les premières itérations du projet et/ou que les spécifications fonctionnelles ne sont pas fixées, est alors quasi instantanée, et on ne se retrouve pas avec des bugs de mapping en permanence.
    Mais c'est justement là, que les entreprises font faillite. tant que les données sont peanuts, alors le système crache... Dès que le volume arrive les performances chutent dramatiquement et l'un (le dev) accuse l'autre (la prod) de pas avoir pris le bon serveur... (bataille du muscle contre l'intelligence comme dirait rudi...). Le problème est que c'est inégal. Un bon schéma (cela n'arrive jamais avec hibernate) avec de bon index (Hibernate n'en pose jamais) c'est un facteur 100 à 10000 au niveau des performances. Rien à voir avec le doublement des cœurs ou de la RAM !

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

  17. #197
    Membre expert
    Profil pro
    Inscrit en
    août 2006
    Messages
    3 192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 3 192
    Points : 3 986
    Points
    3 986

    Par défaut

    @SQLpro
    Je peux aussi vous dire qu'en 11 ans d'expérience avec Hibernate, sur des petits projets comme des gros, je n'ai pas rencontré de problèmes liés à son utilisation.
    Les problèmes étaient plutôt dus à une méconnaissance du framework ou plus généralement, de la base de données utilisée, et ils ont été résolus sans entraîner de dépôt de bilan...
    Vous êtes tellement orientés contre les ORM que vous perdez toute objectivité....dommage...

  18. #198
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 858
    Points : 6 898
    Points
    6 898

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Pour en avoir vu de multiples fois en audit, les requêtes pissées par Hibernate sont en général le summum du crétinisme... Exemple 185 requête avec WHERE toto = 245 puis WHERE toto = 851 etc, au lieu de WHERE toto IN (245, 851...) générant des round-trip en pagaille pendant une transaction... les verrous étant maintenant pendant tout ce process on constatait 99% du temps consacré au réseau pour 1% de réel traitement de la part du SGBDR !!!
    1. DB2 est plus performant en requête séparée qu'avec un IN
    2. Hibernate ne fait que ce qu'on lui demande. Si tu écris une boucle infinie, il faut pas incriminer le langage ou le compilateur ...
    3. Certaines routines ETL ne consomment qu' 1% de traitement SGBDR et 99% de trafic réseau

    Citation Envoyé par SQLpro Voir le message
    Parlons de la méthode de pagination d'Hibernate qui consiste pour chaque page à afficher de reparcourir toutes les données : Superbe !!!
    Je connais pas tous les SGBD mais au moins pour MySQL, Oracle et Postgres, il utilise les mécanismes de pagination proposé par leurs moteurs.
    Après il est reconnu que la pagination par position n'est pas la plus optimale : http://blog.jooq.org/2013/10/26/fast...e-seek-method/
    Citation Envoyé par SQLpro Voir le message
    Parlons aussi des jointures spaghetti qu'Hibernate génère à outrance....
    Les jointures sont celles demandées, là-dessus Hibernate ne fait qu'une seule supposition : par défaut il jointe par clé (ce qui est logique ...)
    Citation Envoyé par SQLpro Voir le message
    Pour ma part en 15 ans d'audit, j'ai vu deux entreprises faire faillite à cause des mefaits d'Hibernate...
    En bien moins d'expérience, j'ai rarement vu un ingénieur qui maitrisait un minimum correctement Hibernate. C'est généralement un outil imposé qui semble magique et donc personne ne veut investir dessus, bien à tord !
    Citation Envoyé par SQLpro Voir le message
    je n'ai pas dit que c'était inexact.. j'ai dit que c'était utopique et d'ailleurs une même requête dans Hibernate provoque des résultats différents dans les différentes SGBDR, ne serait-ce qu'à cause de la gestion des collations...
    +1
    Citation Envoyé par SQLpro Voir le message
    Mais c'est justement là, que les entreprises font faillite. tant que les données sont peanuts, alors le système crache... Dès que le volume arrive les performances chutent dramatiquement et l'un (le dev) accuse l'autre (la prod) de pas avoir pris le bon serveur... (bataille du muscle contre l'intelligence comme dirait rudi...).
    En général le problème c'est le développeur. Celui-ci considère que tant que ca compile et éventuellement que ca s'exécute, il a fait son job. Or c'est faux. Tant que la communication inter/intra système ne correspond pas aux exigences du système (temps de réponse, conso CPU/RAM, volume réel, concurrence, etc.), le boulot n'est pas terminé et il y a un bug. Ce problème n'est pas spécifique à l'utilisation d'Hibernate.
    S'il le développeur ne veut pas comprendre ou qu'il n'y a personne pour lui faire comprendre, le problème n'est pas Hibernate mais ailleurs.

    Citation Envoyé par SQLpro Voir le message
    Un bon schéma (cela n'arrive jamais avec hibernate)
    Le but d'Hibernate (ou de tout ORM) étant au final de stocker des objets dans une base relationnelle, le schéma idéal est donc celui qui permet de contenir des objets. Il y a quelques règles mais aucune qui ne pose de difficulté à un SGBDR.
    Seulement, au final (de mon expérience), Hibernate est souvent utilisé sur une base dite legacy. Ce qui donne naissance à un certain nombre de contorsion.

    Citation Envoyé par SQLpro Voir le message
    de bon index (Hibernate n'en pose jamais) c'est un facteur 100 à 10000 au niveau des performances.
    La pose des index c'est souvent du ressort du DBA ou du développeur (dans une certaine limite). Les indexes sont des objets qui peuvent grandement améliorer les performances mais il ne faut pas oublier qu'ils peuvent être ignorés et plomber les perfs (si le coût de leur maintien est trop important).
    De plus, avoir de bons indexes demandent une bonne connaissance du SGBDR retenu et de l'utilisation des données par l'application. Donc rien qu'Hibernate puisse évaluer.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  19. #199
    Futur Membre du Club
    Inscrit en
    janvier 2007
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 6
    Points : 6
    Points
    6

    Par défaut

    Après plusieurs années au travail à utiliser l'architecture logicielle "classique" (Spring, Hibernate, JPA etc.), j'ai testé cette approche à la maison sur un projet personnel assez conséquent...

    Elle a un inconvénient: il faut bien connaitre SQL (pas un souci dans mon cas). Pour le reste, c'est tout simplement "une tuerie" , le plus bluffant étant l'amélioration des performances!

    Je vais tenter dans mon entreprise d'en vanter les mérites sur un projet test, et propager la bonne parole. Je sais que les résistances vont être forte, la faute aux habitudes bien ancrées et à la méconnaissance du SQL et des SGBD en général.

    Merci de m'avoir fait (re)découvrir cette approche, frappée du sceau du bon sens !

  20. #200
    Nouveau Candidat au Club
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juin 2003
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2003
    Messages : 2
    Points : 1
    Points
    1

    Par défaut to be ORM or not ORM

    Bonjour à tous,
    Je suis tombé par hasard sur ce commentaire tellement vrai, je n'ai jamais compris l'intérêt de ces ORMs...ça doit satisfaire une catégorie de "développeur" qui ne pensent qu'a pondre dans un temps record des "applications" pour s'attirer les grâces d'un management qui ne comprend toujours pas que le développement est un vrai métier et que sans une approche "bottom-top" le projet est voué à l'échec...ha non j'oubliais, il suffit de mettre en place des "caches misères" et des WebServer avec 16CPU et 100Giga de RAM pour résoudre les problèmes de montée en charge...
    On pourrait se dire que le pire est passé, car beaucoup sont revenus sur l'utilisation de se genre de Framework et ont finalement compris qu'il fallait un vrai travail d'analyse au niveau du modèle et de l'accès aux données à travers des Stored Procedure, mais non les bases No-SQL sont maintenant là !!!! C'est tellement pratique de ne pas avoir à réfléchir à Modèle Relationnel de Données et de stoker "as-it-is" ce que l'on a à l'écran et là aussi en cas de problèmes de performance on rajoute juste des Nodes et l'affaire est dans le sac !!!
    Tout cela fait le bonheur des fabriquant de matériel et de hosting !!! Pourquoi normaliser un modèle de données, il faut réfléchir et ça prend du temps !!! En plus il faut écrire des SP et pondre des object POCO/DTO alors qu'une boiboite fait tout ça en coup de cuillère à pot !!! Quel temps perdu...
    Bref, j'attends le moment où l'on aura tellement de data non structurées que même les plus grosses infra ne pourront plus les traiter...
    Cela fait des années que je travaille sur l'optimisation de DB de plusieurs tera et comme par magie des requêtes qui prenaient plusieurs dizaines de minutes ce sont soudainement exécutées en quelques secondes !!!
    Les vrai SGBDR ont encore de beaux jours et les DBA sont encore au chaud pour quelques temps !!!
    Florian

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, 12h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 20h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 09h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 09h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 24/11/2008, 00h13

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