Forum Programmation.java sgbd embarqué - java

Posté par  .
Étiquettes : aucune
0
10
mai
2005
bonjour,

je souhaite réaliser un programme en java avec une base de données embarquée.

J'ai trouvé :
_ HSQL
_ Berkeley DB JE
_ SQLite
_ McKoiDB
_ Derby

Mais je n'arrive pas à trouver des retours d'expérience sur ces différentes solutions, alors je ne sais pas quoi choisir.

J'ai lu quelques sujets de ce forum qui en font mention, mais pas pour une utilisation avec java.

Si vous avez quelques avis sur la question, merci.

  • # BDB

    Posté par  . Évalué à 1.

    Moi je me suis servi de Berkeley DB , c'est bien pratique pour stocker des informations "toutes betes" ... la documentation - tres bien faite - se trouve ici, en 5 min tu devrais avoir une bonne vue d'ensemble de ses possibilités

    http://www.sleepycat.com/jedocs/GettingStartedGuide/BerkeleyDB-JE-G(...)

    Mais ca n'a rien a voir avec une base SQL, ca permet juste de stocker des données et de les recuperer de maniere tres simple.

    Si ta base de donnée embarquée doit contenir des enregistrements tout bêtes de données, je te dirais d'utiliser Berkeley DB, sinon d'utiliser une base embarquée qui supporte completement ou en partie SQL.

    Note : cette version de BDB n 'est pas compatible avec celle que l'on trouve sur nos unix.

    • [^] # Re: BDB

      Posté par  . Évalué à 1.

      J'ai regardé la doc de BDB, et je ne crois pas que se soit approprié pour le type de recherche que je veux faire : lister les commandes réalisées par le client numéro 1 par exmple.

      je vais donc me tourner vers quelque chose avec sql.
      j'hésite encore entre hsql, derby et sqlite

      je crois que pour sqlite, il n'y a pas de jdbc officiel ? je suis donc rétissant a utiliser des wrapper si je suis pas sur de leur fiabilité. est ce que quelqu'un les a utilisés ?

      On m'a dit que hsql était lamentable niveau performance, est ce quelqu'un peut confirmer (ou non), cela.

      merci

      • [^] # Re: sgbd embarqué - java

        Posté par  . Évalué à 1.

        bonjour ,
        moi je vais faire le mm truc que que toi et aprés des jours de recherche g choisi derby (couldscape) la doc elle est bien faite
        derby est ecri en java donc t aura pa de probleme s integration tu met directement le jar et ça marche

        il ya pa presque des limites pour la base

        moi personellement j te conseille de l'utiliser

  • # XML ?

    Posté par  (site web personnel) . Évalué à 1.

    Le xml peut etre une solution

    Il y a de tres bons parseurs qui te machent le travail.
    Documentation à foison (peut-etre trop)

    Enfin voila c jeune, c fun, c frais, ca plait au filles => Faites du XML

    • [^] # Re: XML ?

      Posté par  . Évalué à 1.

      Le xml c'est lent, c'est chiant, c'est pas fun du tout, je ne vois pas l'interet quand on te demande une base => faites du xml quand c'est un réel besoin

      • [^] # Re: XML ?

        Posté par  (site web personnel) . Évalué à 1.

        >c'est lent
        as tu des comparatifs sérieux ? tu as testé combien de parseurs ?

        >c'est chiant
        C'est sure que vu l'age du SQL, beaucoup de personnes savent en faire, mais l'utilisation du XML est quand meme bien simplifier avec les bibliotheques qui vont bien... C'est pas parce que le XML te rebute, que ca va rebuter tout le monde

        >quand on te demande une base
        Oui enfin ca revient au meme, ici on parle pas de base embarquée ->une bibliothèque qui va aller lire et écrire dans des fichiers... Pour moi Xml avec la bonne bibliotheque c'est pareil.

        Et en plus il pourra aisement partager sa base...
        On peut meme faire des requetes sur du XML. C'est sure, ca va pas etre un "LEFT JOIN UNION plop.* where select etc etc " mais bon...

        • [^] # Re: XML ?

          Posté par  . Évalué à 1.

          1. XML est bien plus lent que, par exemple :

          * un fichier texte type /etc/passwd
          * un SGBD
          * un moteur de recherche

          Pas besoin de comparatif c'est une évidence ... ( mais si tu veux je serais heureux de comparer une jointure entre deux fichiers XML )

          2. je trouve, mais ca ne regarde que moi en tant que développeur, que le XML c'est chiant à manipuler, c'est pas trop dur à faire bien entendu, mais c'est pas le genre de truc ou je prend mon pied à coder, donc oui pour moi le XML c'est chiant ... comme le SQL d'ailleurs, je le laisse aux autres

          Le xml c'est vraimment tres bien, mais dans certains cas, et le tout XML est une erreur à mon avis

          3. Apparement il souhaite quand meme faire plus que du stockage, cf le post sur berkeley DB .

          4. Oui on peut requeter du XML, et ... ca rame plus que honteusement


          Bref le XML présente de nombreux avantages mais aussi des inconvénients, et son choix demande reflexion ...

          • [^] # Re: XML ?

            Posté par  (site web personnel) . Évalué à 1.

            1. XML est bien plus lent que, par exemple :

            * un fichier texte type /etc/passwd
            * un SGBD
            * un moteur de recherche


            Tu sors toute une armée là.
            Il cherche juste une base de données embarquées.
            Un fichier /etc/passwd n'est pas vraiment evolutif comme solution non plus... C'est sure qu'un fichier bien formaté comme il faut avec du binaire à l'intérieur ca torche mais bon c'est moins souple...

            Encore une fois tout est question de parseurs et de bibliothèques,
            Si tu stockes tes données dans un SGBD sans positionner tes index tres judicieusement, ca va pas etre top non plus

            Bref un peu de raisonnement, de l'huile de coude et un brin de raisonnement apportera des solutions tout aussi efficace

            Puis bon pour de l'embarqué, il va pas faire une base de 3To non plus je pense...

            Bref le XML présente de nombreux avantages mais aussi des inconvénients, et son choix demande reflexion ...

            Bon et bien nous sommes d'accord.
            Notre lecteur pourra choisir le choix qui lui convient le mieux après reflexion

            le tout XML est une erreur à mon avis

            On s'est mal compris je pense, je ne prone pas le tout XML

  • # Derby

    Posté par  . Évalué à 1.

    Personnellement j'ai testé hypersonic (hsql) et Derby -- anciennement cloudscape -- pour un projet nécessitant un sgbd embedded.

    Je préfère largement Derby qui offre un bien meilleurs support SQL (à l'image de DB2) et permet de faire du managment de base par les url jdbc avec des paramètre style ?create=true ou ?shutdown=true

    • [^] # Re: Derby

      Posté par  (site web personnel) . Évalué à 1.

      J'ai aussi une experience tres positive de Derby :
      - Bon support SQL (c'est agréable de pouvoir écrire FOREIGN KEY REFERENCES ma_table ON DELETE CASCADE).
      - Pas de probleme de performence (même avec des Blob)
      - Compatibilité des types avec java (prévue pour être utilisé avec JDBC)
      - Possibilité d'utiliser en serveur (pas testé) ou en embarqué
      - Mise en oeuvre triviale (un jar à mettre dans ton classpath 2 si tu veux les outils)
      - Libre

      Ceci dit, je n'ai pas l'experience des autres bases dont tu parles et qui sont sans doute tres valables.

  • # Méthode de choix

    Posté par  . Évalué à 1.

    Déjà, évite tout ce qui n'est pas standard SQL : exit Berkeley DB

    Ensutie, pour de l'embarqué en java, prend un base en pur java : exit SQLite.

    Il ne te reste que Derby, HSQL, McKoi.

    Perso, j'ai utilisé un peu McKoi et je le trouve vraiment très bon. Par contre, le développement a ralentit après la sortie de la version 1.0, et c'est maintenant un peu au ralenti.

    Au contraire, HSQL est utilisé par de nombreux projets opensource (Jonas par exemple), et est très actif.

    Pour Derby, ben je viens de découvrir seulement son existence, alors j'ai rien à ajouter.

  • # Sqlite wrapper

    Posté par  . Évalué à 1.

    j'essay d'utiluser un wrapper pour sqlite je l'ai telechargé sur http://www.ch-werner.de/javasqlite/index.html(...)
    mais j'arrive pas a l'installer est ce que qq1 a deja utiliser un JDBC ou
    un wrapper pour sqlite.
    en sachant que je suis obligé d'utiliser sqlite j'ai pas du tout le choix

    tout aide serai le bien venu merci a tous

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.