IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

ORM vs OODB vs EJB vs JDO vs JPA !


Sujet :

Décisions SGBD

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 220
    Points : 100
    Points
    100
    Par défaut ORM vs OODB vs EJB vs JDO vs JPA !
    Bonjour à tous.

    Dans le cadre du développement d' une application wed (en intranet) reposant sur une base de donnée (coeur du problème), pour une entreprise, j'aimerais avoir vos avis quant aux choix de la technique à mettre en oeuvre pour developper cette application.

    Je souhaite développer en java, mais ce n'est pas un choix définitif ! En tous cas je désire FORTEMENT dévelloper avec un langage Orienté Objet et surtout surtout avec un " concepte" base de donnée OO (db4o par example) ou ORM/RDBMS(Hibernate par example) !

    J' aimerais avoir vos avis sur la question, et que vous éclairiez ma lanterne aux sujet des EJB, JDO et JPA car je n' ais pas bien compris leurs fonctionnalités et si ils peuvent être appliquer à mon logiciel.

    PS: Je pense avoir compris l' intérêt des OODBMS et ORM/RDBMS mais je ne voudrais pas passer à côté des autres technologies disponibles (EJB, JDO et JPA ) !

    Je ne sais pas si je me suis bien fais comprendre, n'hesitez pas à me demander.

    Cordialement.

  2. #2
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Une partie de la réponse dépendra largement du SGBD utilisé. Vous ne le mentionnez pas.

    Ensuite, les ORM, comme le souligne régulièrement SQLPro, c'est avant tout une perte de performances, de temps, de maintenabilité et de compétences.
    - De performances car sorti d'une jointure simple, aucun ORM ne sait faire de requête complexe en base. Par conséquent, ça fait des millions d'allez-retour dans la base au moindre traitement, et augmente les temps de réponse de façon exponentielle
    - De temps, car la mise en oeuvre de ce genre d'outils est souvent largement plus complexe que l'outil lui-même, que chaque limitation de l'outil force le développeur à revoir son analyse 20 fois par jours, et j'en passe de meilleures
    - Maintenabilité, car rapidement, face aux limitations, on va commencer à bidouiller à droite à gauche pour contourner ce joyeux bordel. Au bout de 15 jours, plus personne ne sais comment ça fonctionne, et tout le monde passe en mode débogage au lieu de développer
    - Compétences, car à forde d'interroger la base sans en voir le modèle, plus personne ne sait faire de SQL, et surtout plus personne ne sait à quoi ressemble la base de données, et donc fait n'importe quoi dedans

    Un ORM, c'est bien quand 1000 personnes travaillent sur un même projet, qu'elles ne parlent pas la même langue, ne travaillent pas au même endroit, et qu'il faut une ligne directrice pour que chacun ne réinvente pas la poudre. Cela demande une rigueur importante, et est absolument inadapté à un projet de taille "humaine" (genre 3 pékins qui développement dans la même pièce, comme le sont 99% des développements)

    Contentez-vous, c'est mon conseil, de développer avec une architecture multi-couche : vous aurez toujours une approche objet de votre base de données (pas besoin de se palucher les requêtes dans la partie métier), mais une maîtrise totale des traitements dans la base de donnée.
    En plus d'être plus simple à implémenter, c'est aussi plus rapide et plus facilement maintenable.

    Après, niveau choix du langage, perso, je hais de tout mon être Java. Mauvaise expérience certainement. Je lui préfère largement .NET d'autant qu'avec Linq to SQL et Linq to Entity, on peut largement simplifier les accès aux données.
    On ne jouit bien que de ce qu’on partage.

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Les bases de données objet sont mortes depuis de nombreuses années par pure darwinisme... En effet il n'est pas possible d'indexer n'importe quel type d'objet, tant est si bien que les performances de telles bases de données ont été catastrophiques. C'est la raison de leur mort...

    L'utilisation d'un ORM est très contre performant. En gros vous mettez entre 5 et 50 fois plus de temps à faire le même traitement dans votre ORM que si vous l'aviez fait directement en base de données via des procédures stockées.

    On dit d'ailleurs des ORM que c'est le Vietnam de l’informatique et ce terme est parfaitement justifié et adéquat. En effet il n'existe pas de lien direct entre un objet et sa représentation en base. C'est le problème du défaut d'impédance. De plus il faut se farcir de nombreux "round trip" entre la base et l'ORM pour manipuler un objet, ce qui cause les problèmes de perf. Enfin, les requêtes écrites par les ORM nivellent par le bas la qualité du SQL (pour s’adapter à tous les SGBDR il faut utiliser les éléments communs du SQL des différents SGBDR ce qui revient la plupart du temps à ne faire que du SELECT *....)

    À lire : http://ormeter.net/
    Vous y lirez par exemple qu'un simple UPDATE fait par NHibernate est 24 fois plus lent qu'un UPDATE directe en SQL...

    La question se résume donc à :
    voulez des performances ou vous contenterez vous d'un système lent au départ et dont les temps de réponse vont se dégrader encore plus lors de la montée en charge ?

    Dans ma carrière j'ai rencontré en audit une bonne dizaines de boîtes ayant versé dans l'ORM à tout craint parce que c'était soit disant plus rapide en développement (ce qui est vrai pour des maquettes ou de très petits projets et bien entendu totalement faux pour des applications conséquentes). Le résultat de l'audit "tait à chaque fois très clair :
    • supprimez la couche ORLM
    • remodélisez votre base de données

    Bref une application a récrire entièrement.
    Parmi cette dizaines, deux boîtes ont coulées à cause de cela : incapacité de monter en charge alors que l'on avait vendu le logiciel à un très gros client, donc, rupture de contrat, non paiement, procès....

    À lire de manière plus globale : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

    Enfin, si tout de même vous persistez dans cette approche débilitante qu'est l'ORM, sachez que le pire, c'est justement Hibernate !
    Mais avant de plonger dedans, voici un document à lire http://discuss.joelonsoftware.com/de...?joel.3.219431

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre régulier
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 220
    Points : 100
    Points
    100
    Par défaut
    A StringBuilder.

    Une partie de la réponse dépendra largement du SGBD utilisé. Vous ne le mentionnez pas.
    J'avais pensé à postgresql.

    De performances car sorti d'une jointure simple, aucun ORM ne sait faire de requête complexe en base

    Une vraie base de donnée OO le peut elle?

    De temps, car la mise en oeuvre de ce genre d'outils est souvent largement plus complexe que l'outil lui-même
    En effet je pense que cela doit être long, mais le temps doit "théoriquement" être rattrapé après, non?


    Compétences, car à forde d'interroger la base sans en voir le modèle, plus personne ne sait faire de SQL
    Je serais le seul a développer dessus!


    Contentez-vous, c'est mon conseil, de développer avec une architecture multi-couche
    Je ne vois pas trop à quoi vous faite allusion.

    Après, niveau choix du langage, perso, je hais de tout mon être Java
    Java n'est pas définitif, j'envisage python (django) et ruby (on rails).


    A SQLpro.


    Les bases de données objet sont mortes depuis de nombreuses années par pure darwinisme... En effet il n'est pas possible d'indexer n'importe quel type d'objet, tant est si bien que les performances de telles bases de données ont été catastrophiques. C'est la raison de leur mort...
    N'est-ce pas simplement par méconnaissance du fonctionnement de celles-ci?


    En effet il n'existe pas de lien direct entre un objet et sa représentation en base.
    Désolé, je ne comprend pas

    La question se résume donc à :
    voulez des performances ou vous contenterez vous d'un système lent au départ et dont les temps de réponse vont se dégrader encore plus lors de la montée en charge ?
    Je ne recherche pas la performance à l'exécution mais au temps passé au développement.

    Merci pour vos réponses.

    Auriez vous la gentillesse de m'en dire plus à propos des EJB, JDA et JPA SVP?

    D'avance merci.

  5. #5
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Pour le choix du SGBD, je vous conseille fortement SQL Server (version Express si vous voulez du gratuit) ou Oracle (version XE si vous voulez du gratuit).

    Malgré les limitations des versions gratuites, vous aurez entre les mains un SGBDR "réel" (SQLpro vous expliquera ça mieux que moi) des performances redoutables, et des systèmes proches de la norme et bourrés de fonctionnalités aussi exotiques que nécessaires, même pour des petits projets.

    Si vous choisissez de tourner sous Windows, le choix de SQL Server est absolument trivial, il n'y a pas la moindre question à se poser.


    Vous remettez en cause la connaissance de SQLpro à propos des bases OO, retirez très vite ce que vous avez dit, ou vous allez finir sur un bûcher
    SQLpro semble extrêmement au courant de ce qu'il dit, il a d'ailleurs écrit plusieurs livres, qui sont des références, sur le SQL. Je pense que s'il vous déconseille les bases OO, vous pouvez l'écouter les yeux fermés, même s'il y a des pieux acérés tout autour de vous.

    Perso, j'y connais rien, mais rien que le concept me semble parfaitement bancal.


    Ensuite, si vous êtes seul, un ORM ne sera qu'une perte de temps.


    Ce que j'entends par programmation multi-couche, c'est par exemple ça :
    http://msdn.microsoft.com/fr-fr/library/bb384398.aspx
    http://immobilis.developpez.com/arti...ouche-asp-net/

    (j'ai pas lu les articles, juste vérifié que ça parle de la même chose que moi)

    En gros, ça consiste à créer plusieurs couches (généralement 3), afin de séparer les objets purement "data" (connexion à la base de donnée, récupération des jeux de résultats, modification des données, etc.") les objets "métier" (représentation objet des entités de la base de données, traitements, intelligence du programme) et les objets "présentation" (les contrôles utilisateurs, le rendu final.

    Par exemple, on a généralement 3 objets de ce type :

    (donnée) dataProvider : qui contient "getData" avec en paramètre une requête SQL, "setData", avec la même chose, etc.

    (métier) objPerson : qui contient "load/save", qui appellent les méthodes de dataProvider, ainsi que "addAddress", qui va créer un objet address, qui fait la même chose, que personne, mais avec des données d'adresse, etc.

    (présentation) viewPerson : qui est un contrôle utilisateur qui affiche la fiche signalétique d'une personne. Le constructeur appelle objPerson.load(), le bouton "Save" appelle objPerson.save()" et le sous-contrôle "viewAddress" fera des "addAddress()" quand on rajoutera des adresses dedans.

    Je sais pas si c'est très clair. Les articles en question le sont certainement plus !
    On ne jouit bien que de ce qu’on partage.

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 220
    Points : 100
    Points
    100
    Par défaut
    Merci StringBuilder.


    J'avoue ne plus savoir quoi penser!

    J'avais développé, il y a 10 ans de ça, une application de A à Z tout en SQL et C++(VisualC++) sur un SGBDR (Access il me semble)..... brouuuuu.... j'en frissonne encore

    A la fin, je n' en pouvais plus ! je ne m'y retrouvais plus dans mon code, et il n'y avait pas plus d'une 20 ène de tables!

    Le pire, c'était pour ajouter et/ou modifier les données.

    J'avoue ne jamais avoir eut à faire à un ORM, et je me souvient des collègues de bureau, avec qui je développais une appli (moi je m'occupais uniquement de la partie IHM), pestant contre hibernate qui leur mettait les nerfs à rude épreuve.


    Moi de mon côté, j'avais eu l'occasion de "tester" une paire de base de donnée OO (FastObject et db4o il me semble), et le peu que j'en avais vu, m'avait paru "extraordinaire".

    J'en avais conclu que le problème venait d'hibernate et qu'ils n'avaient (les collègues) qu'a utiliser une vrais base OO.

    Quelqu' un aurait-il un avis sur la question?

    D'avance merci.

    PS: SQLpro, peux tu poser ce fusil à pompe STP?

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par flyingman Voir le message
    PS: SQLpro, peux tu poser ce fusil à pompe STP?
    C'est vraiment pas mon genre.... Plus je vieillis plus je constate les dégâts occasionné par le fait que l'on enseigne de moins en moins les fondamentaux (que sont les données par exemple....) au profit de produits cosmétiques (flash, CSS, ...).
    Et comme en sus j'enseigne dans différentes écoles d'ingé, là je sévit sur les notes. Au départ la première interro, ils ont tous entre 0 et 8 !!! En fait ils croient savoir quelques chose sur la modélisation des bases de données par le fait qu'ils ont bidouillé sur MySQL ou Access et lu des conneries sur le web !
    En 10 ans le web est devenu le pire ramassis de crétins....
    N'importe quel quidam, sous prétexte qu'il a réussit à aligner 3 bout de code poste son exploit et vante sa solution, sans jamais n'avoir vu autre chose ni effectué la moindre comparaison !
    Bref, un nivellement par le bas des connaissances.

    Par exemple vous vous pensez que les SGBD OO vont vous sauver, mais vous commettez deux erreur :
    1) il n'en existe plus pour les raison que j'ai déjà évoqué
    2) tous les bon SGBDR (Oracle, SQL Server par exemple) permettent en sus des capacité relationnelles de faire de l'objet...
    Depuis la norme SQL:1999 l'objet à été introduit dans les SGBD Relationnel, c'est pourquoi on parle de SGBDRO !

    Et puis j'ai décidé de faire le méchant ! Plusieurs avantages :
    1) ça me défoule
    2) ça rentre mieux dans le crâne des posteurs
    En effet, plus personne ne va voir Sissi Impératrice... mais plutôt Terminator !!!

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. ORM vs OODB vs EJB vs JDO vs JPA !
    Par flyingman dans le forum Autres SGBD
    Réponses: 2
    Dernier message: 09/08/2012, 09h29
  2. JDO vs JPA que choisir ?
    Par Blustuff dans le forum Persistance des données
    Réponses: 7
    Dernier message: 19/02/2009, 12h26
  3. JDO contre JPA
    Par ouatmad dans le forum Persistance des données
    Réponses: 1
    Dernier message: 12/01/2008, 13h28
  4. [EJB2] Sources de données pour EJB
    Par thomy dans le forum Java EE
    Réponses: 4
    Dernier message: 04/06/2003, 16h52
  5. [EJB] Débutant en EJB sur Weblogic
    Par viny dans le forum JBuilder
    Réponses: 8
    Dernier message: 24/04/2003, 16h34

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