Discussion :

[rastalien73]

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

[ohanny]

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 ?

[rastalien73]

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

[ohanny]

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.

[JeitEmgie]

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…)

[rastalien73]

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

[JeitEmgie]

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
…