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

JPA Java Discussion :

Quel JPA Provider ?


Sujet :

JPA Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut Quel JPA Provider ?
    Bonjour,
    Dans le cadre d'un projet de RCP Eclipse j'ai besoin d'utiliser la persistence d'objet.
    Il s'agit d'avoir une API orienté objet permettant de manipuler des objets persistés sans se soucier du code SQL.

    Mon application utilise la base de donnée embarquée SQLite.

    Une première approche à été de comparer les performances entre une API faites maison qui génère du code JDBC et l'utilisation du framework Hibernate.

    Premier problème Hibernate ne supporte pas "nativement" SQLite. Ensuite après avoir fourni un dialect SQLite à Hibernate il s'avère que les performances obtenu sont insuffisantes pour mon application (requêtes trop lentes).

    Aujourd'hui l'API "maison" existante à atteint ses limites et je souhaiterais savoir si parmi vous quelqu'un aurait testé un autre JPA provider (EclipseLink ? éventuellement avec une autre base de donnée embarqué) et qui aurait des performances se rapprochant de celles de SQLite ?

    Cordialement

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Janvier 2009
    Messages : 92
    Par défaut
    Le passage à un ORM est un choix qui n'est pas sans conséquence. Compte-tenu de l'importance de cette décision, ne faudrait-il pas d'abord se poser la question de la base de données => SQLite vraiment indispensable ? si il faut absolument garder SQLite, n'y a t'il pas un risque d'évolution puisque peu d'implémentations JPA supportent SQLite ?

  3. #3
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut
    Compte-tenu de l'importance de cette décision, ne faudrait-il pas d'abord se poser la question de la base de données => SQLite vraiment indispensable ?
    SQLite n'est pas indispensable, c'est la solution existante aujourd'hui. Ce qui est indispensable c'est l'utilisation d'un SGDB fichier (embedded) performant (D'après mes recherches je n'en ai pas trouver de plus performant que SQLite... Mais toute solution aussi performante est bien sur envisageable ).

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Janvier 2009
    Messages : 92
    Par défaut
    Si la performance est un élément essentiel, il faut noter que de toute façon, l'utilisation d'un ORM générera un overhead. Je pense qu'il faut surtout choisir le couple bdd-orm qui conviendra le mieux, plutôt que choisir chaque élément séparément => tu peux perdre sur une bdd, mais te rattraper sur l'orm. Maintenant, je ne saurai pas te conseiller sur les perfs des uns et des autres, mais si garder sqlite impose une implémentation jpa qui n'est pas très performante, les temps de réponse globaux s'en resentiront.

  5. #5
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par rastalien73 Voir le message
    SQLite n'est pas indispensable, c'est la solution existante aujourd'hui. Ce qui est indispensable c'est l'utilisation d'un SGDB fichier (embedded) performant (D'après mes recherches je n'en ai pas trouver de plus performant que SQLite... Mais toute solution aussi performante est bien sur envisageable ).
    définissez précisément "embedded" dans le cadre de votre projet …

    (j'ai déjà vu des applications "desktop" qui utilisait PostgreSQL de manière "embedded"… càd que le serveur PosgreSQL n'existait que tant que l'utilisateur final ne quittait pas l'application standalone… et l'ensemble des dossiers et fichiers de PostgreSQL nécessaires au fonctionnement était packagé dans l'application elle-même… l'utilisateur final ne voyant qu'un fichier fichier : le package de l'application…)

  6. #6
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut
    définissez précisément "embedded" dans le cadre de votre projet …
    Cela signifie qu'idéalement, ma base est sauvegardé dans un fichier (a la SQLite != Derby par example) et qu'aucun serveur est nécessaire en demon puisqu'il s'agit d'une application standalone local.

    Si j'ai compris ce que vous proposiez, il s'agit de démarrer un serveur, Postgres en l'occurence, le temps que l'application est éxécuté ?
    Dans ce cas, quid des performances ?

    - Au niveau de la charge à l'éxécution
    - Performance entre une BD embarquée fichier comme SQLite et une BD serveur (MySQL,Postgres...)

  7. #7
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par rastalien73 Voir le message
    Cela signifie qu'idéalement, ma base est sauvegardé dans un fichier (a la SQLite != Derby par example) et qu'aucun serveur est nécessaire en demon puisqu'il s'agit d'une application standalone local.

    Si j'ai compris ce que vous proposiez, il s'agit de démarrer un serveur, Postgres en l'occurence, le temps que l'application est éxécuté ?
    Dans ce cas, quid des performances ?

    - Au niveau de la charge à l'éxécution
    - Performance entre une BD embarquée fichier comme SQLite et une BD serveur (MySQL,Postgres...)
    "proposer" est un bien grand mot, j'attire l'attention sur le fait que cela reste une possibilité…

    "dans un fichier" : l'air de rien, ça limite très fort le choix…
    la plupart des SGBD vont séparer tables, indexes, meta infos… dans plusieurs fichiers…
    "dans un fichier ou un dossier" c'est déjà plus souple…

    de quelle "performance" parlez-vous ?
    du temps de lancement de l'application ?
    si c'est fait intelligement : aucune différence… le serveur démarrera en parallèle du chargement de l'UI…

    de l'exécution des requêtes ?
    plus elles sont complexes (join and C°) plus PosgreSQL aura l'avantage

Discussions similaires

  1. Réponses: 5
    Dernier message: 24/05/2011, 10h27
  2. Réponses: 7
    Dernier message: 22/06/2010, 17h26
  3. [E03] ADO vers DB AS400 : Quel provider utiliser ?
    Par Godzestla dans le forum Macros et VBA Excel
    Réponses: 1
    Dernier message: 20/01/2009, 09h33
  4. Réponses: 2
    Dernier message: 02/12/2008, 11h56
  5. quels sont les avantages de jpa
    Par une_tite_question dans le forum JPA
    Réponses: 6
    Dernier message: 09/05/2008, 11h39

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