Reprise du message précédent :

 
SQLite...

En java, il y a aussi hsqldb et Apache Derby

Autant de raisons d'éviter l'XML

Mais tu parles à MagicBuzz

Je veux importer le moins de données possible sur le client, pour éviter au maximum les problèmes de concurrence entre les utilisateurs au moment de la synchronisation.
Le XML, ça me plaisait bien. Et ça me permettrait de l'envoyer sous cette forme au serveur, non ?

Derby semble très mauvais niveau perfs d'après mes tests avec PolePosition. Par contre, HSQLDB et H2 boostent bien, avec un avantage pour HSQLDB. Mais
"HSQLDB looks very good on many graphs, because most of the processing is done in memory. We did not dig deep enough into HSQLDB source code, to understand if the behaviour is fully compliant with ACID principles. Measuring commits to take zero time, even if called repetitively, made us very sceptical. True ACID transactions would require #sync() calls to make sure that all data is flushed down to the hard disc and from the measurements we performed we conclude that #sync() is not called on commit.
Before you consider to use HSQLDB for a complex database application, you should also take a close look at Barcelona:query. The query optimizer does not seem to cope with a query over five tables."

Au passage "f you need a relational database for whatever reason, MySQL should certainly be on your evaluation list. We did test quite a few other proprietary products with the benchmark suite, products that may not be listed here because of their license agreements. These other products did not look good at all. No wonder MySQL has such a big and growing installed base."
Faudrait que je fasse le test avec Oracle...

Ouais enfin là c'est dans le cadre d'un truc webstart, donc une application mono utilisateur, pas besoin de gérer 5000 transactions/seconde

Ouais, c'était juste histoire de dire que je m'amusais à tester les bases en ce moment. Mais il y a des  modifs de source à réaliser sur ce framework de tests, parce que:
a) il n'y a pas de tests de jointures, juste des select ultra basiques, pas de triggers non plus
b) j'ai un peu peur que tel qu'il est fait, le test de select n'avantage un peu trop le cache d'Hibernate, les elect ne sont pas aléatoires, mais tapent sur les premiers éléments d'une table
c) la version d'Hibernate testée est ancienne (v2, alors que la dernière est en 3.5, mais il y a eu changement d'interface)
d) il y a db4o, HSQL, MySQL, Oracle et Derby, mais il manque Postgres, et éventuellement db2
e) il manque des ORM intéressants comme JDO (il y a Versant, mais pas Apache JDO), et JPOX et Ibatis
f) la plupart des jars sont anciens, je les ai déjà mis à jour.

J'ai fait mes tests sous XP/eclipse, donc ça vaut ce que ça vaut...

0x90 + Masklinn : Vos trucs, Java Webstart sait les déployer tout seul ? (c'est une question hein...)
 
Parceque s'il faut installer le soft à part, via un wizzard ou autre, ça me semble relativement bordelique si l'appli doit s'adresser à une brute écervelée de club de foot
 
D'où ma proposition, si Java a un équivalent des DataSet de .NET
 
Franchement, ça marche 100% tout seul : t'es en ligne ? Le DataSet travaille sans problème avec n'importe quel SGBD.
T'es plus en ligne ? Une version sérialisée en local est 100% utilisable et accessible.
T'es reconnecté ? Un petit Merge entre ta copie locale et ce que t'as sur le serveur, toujours sans sortir de l'objet DataSet, et voilà youpi tralala c'est synchronisé...
 
Franchement, niveau utilisateur : rien à faire, une seule application. Côté code : rien à faire tout se gère dans un seul objet, tu te moques totalement de ce qui se fait derrière, le framework est là pour toi.
 
Par contre, jamais personne ne m'a jamais répondu sur l'éventuelle équivalence de ces objets en Java... En .NET notamment, on gère sans problème les merge entre deux versions, les clés étrangères, on tapes directement dedans en SQL, etc., genre y'a aucun intérêt pour un petit volume à déployer un SGBD sur le poste local, surtout s'il est hétérogène avec celui du serveur... La synchronisation des bases esclave/maître, c'est sympa, mais si on peut éviter de le faire à la main, c'est pas plus mal.