Bonjour !
 
J'ai une question concernant la sdd que je suis en train de mettre en place.
 
J'ai des objets contenant une quantité d'information (texte) assez importante.
Je veux pouvoir obtenir ces Objets suivant certain critères prédéfinis.
Par exemple imaginons que mes objets soient des livres, ils ont donc un auteur, un éditeur, un genre, etc...
 
L'utilisateur doit pouvoir voir (en cliquant sur un bouton) tous les livres de tel auteur ou bien tous les livres de telle ou telle collection, etc...
 
Je pourrais faire une recherche à chaque demande de l'utilisateur, mais cela prendrait du temps (plusieurs milliers d'objets).
Je veux donc stocker mes objets dans un coin, et créer une sdd contenant des références vers ces objets (imaginez un file system où tous les objets seraient mis en vrac dans un coin et où l'on naviguerait au milieu de raccourcis vers ces objets. Plusieurs raccourcis peuvent pointer vers un même objet, et c'est là le but puisque un même livre sera référencé au niveau de son auteur, de son genre, de ses éditeurs, etc...).
 
Jusque là, rien de bien compliqué je pense.
 
Un problème se pose lors de la suppression ou de l'évolution d'un objet (On supprimer un livre de la base, ou bien il change d'éditeur, etc...). Ses références doivent également changer.
Afin de pouvoir mettre à jour facilement ces références, je comptais stocker l'endroit où se trouvaient ces références au niveau de mes Objets (ils sauraient donc où ils sont référencés).
 
 
Ma question est donc :  
 
- Quelle structure de donnée utiliseriez vous pour stocker les Objets (ArrayList ? Vector ? LinkedList ?) sachant que le nombre de ces objets n'est pas fixe, que les opérations critiques sont l'ajout de nouveaux objets, et l'accès à ces objets.
 
- Quelle structure de donnée utiliseriez vous pour stocker les références vers ces Objets ? (nombre non fixe, pas d'opération critique)
 
- Comment géreriez vous la suppression des références d'un objet sachant que cela doit être rapide.
 
Voici un petit dessin qui montre en gros à quoi ca devrait ressembler (dans mon idée) :
 

 
Merci !
 

Histoire de faciliter un peu la compréhension, voici à quoi ressemblerait la structure de mon ensemble de références :
 

Rien qu'en lisant le début de ton message, je dirais... utilise une base de données
Et fais des requêtes en SQL.
 
Ton histoire est on ne peut plus classique.

Ah ben non ce serait trop simple, mieux vaut tout réimplémenter à la main
 
Personnellement je conseille de nester des hashmaps afin d'augmenter l'efficacité d'accès à un élément connu

 
Je suis dans un environnement où je ne peux pas utiliser de base de données...
 

 
C'est ce genre de réponse que j'attends    
Merci !    
 
D'autres avis ?

triple store, rdf, ...
 
 
 
 
 
 

Je vois pas trop d'environnements ou même SQLite ne peut être utilisé perso, mais c'est comme tu le vois

C'était une plaisanterie

 
...
 

 
Je suis sous environnement OSGi et "on" ne veut pas mettre de bdd. (contraintes techniques)
 
Pour la plaisanterie, justement, des HashMaps imbriquées c'est déconseillé ? Si oui pourquoi en fait ?
 
Pour donner une idée du context, cette application est destinée à être intégrée sur une passerelle aux ressources trés limitées. Le parsing XML est assez couteux me semble-t-il, donc une structure XML me semble contre-indiquée non ?

parce qu'a un moment si t'as plus de 10 livres ça risque de devenir un poil lourd pour ta ptite mémoire vive?

 
Bon, la ressource la plus critique dans mon environnement est le temps processeur. Je cherche donc à en limiter au maximum la consommation.
Je tourne sous un environnement OSGi (framework Java destiné à des systèmes embarqués) qui limite mes actions et il a été décidé qu'il n'y aurait pas de bdd installée. J'ai donc droit à du Java et de l'xml si ca vous semble judicieux.

ben, xml, pour ton cpu et la memoire, spa le mieux hein. t'as quelques bdd embarquées et legere en pure java qui peuvent valoir le coup...

 
Bon on est au moins d'accord sur ce point :-)
 
Sinon pour les BDD embarquées, moi je veux bien, mais si elles sont "pures Java", elle doivent exploiter des sdd Java, donc n'y a t il pas moyen de le faire moi même ? J'ai peur qu'utiliser une bdd ce soit un peu comme prendre un rocher pour écraser une fourmie...
 
Mais je veux bien des noms et des avis sur ces bdd, merci    
 
 
Sinon pour revenir sur l'histoire des Nested HashMap, pourquoi est trés lourd pour le processeur ?
 

Quelqu'un pourrait me répondre sur les contre indications au niveau des HashMap imbriquées ?
 
Merci.

taille + coût d'un traversal profond.

hsqldb ?

Salut ikao2,  
 
plusieurs trucs que je capte pas
 
quand tu dis :  

et :  

T'as pas l'impression de te contredire ?  
 

Pourquoi ré-inventer la roue ?  
 

Quelquesoit la manière que t'emploieras pour stocker tes informations et faire des recherches dessus, le résultat sera que tu utiliseras quelquechose qui s'apparente à une bdd ... même si c'est toi qui l'a mise au point.  

Disons que je pense (mais en fait je ne le sait pas vraiment) qu'une bdd offre des fonctionnalités que je n'exploiterai pas...
 
Une autre remarque importante que j'avais oublié : aucune donnée ne doit être sauvegardée de manière persistante sur la passerelle, à chaque démarrage la sdd (ou tout du moins son contenu) est recréée à partir d'information extérieures.
 
Je ne sais pas trop comment fonctionnent les bdd que vous me proposez, mais répondent elles à cette contrainte ? Si vous avez des bdd sous forme de packages JAR qui permettraient de sauvegarder mes infos et les mettre à jour facilement, et ce, de façon temporaire, je suis partant :-)
 
Merci !

ben hsqldb, tu crees une base en memoire, et hop au demarrage suivant ta base est vide
et c'est effectivement uniquement un jar a foutre dans le classpath

 
je vois ... tu te dis qu'il y a une astuce d'encodage de tes données parce que tu crois que ton problème est spécifique. Ben en fait il n'est pas du tout spécifique ; un prof. qui voudrai expliquer ce qu'est une base de données ne trouverai pas meilleur exemple que ton truc à coder  
 
Là d'un coup d'oeil (p'têt que j'ai pas tout capté), je vois 4 tables à créer : livre, auteur, genre, editeur
la table livre possédant un titre et qui fait référence à 1 genre, plusieurs auteurs et plusieurs éditeurs. Ca c'est pour la structure fixe.  
Ensuite tu remplies ta table auteur avec zola, voltaire, etc ... genre avec roman, science fiction, editeur avec gallimard, hachette etc ...  
 
Et le moteur de la B.D. te fais les recherches sur les livres d'après les critères que tu veux tout seul comme un grand. Ca fait beaucoup de raisons pour foncer tête baissé vers une base de données, qu'en penses-tu ?  

 
 
Ok merci pour toutes ces infos, je vais récapituler :
 
L'environnement OSGi fonctionne de la manière suivante : On génère un JAR comprenant le programme Java que l'on veut éxécuter (+ quelques classes nécessaires à OSGi). Ce JAR est installé dans l'environnement et à chaque démarrage de cet environnement, le programme sera lancé. Quand l'environnement est éteint, seul le JAR doit rester.
 
Je voudrai donc que tout mon programme se trouve dans un JAR (bdd hsqldb comprise). A chaque fois que mon programme se lance, il scrute certain serveur pour récupérer un flux XML qui est parsé. C'est ce flux parsé que je veux récupérer et mettre dans une structure temporaire qui n'a de durée de vie que le temps ou mon programme est lancé. Il ne faut donc rien à installer au préalable, TOUT doit se situer dans le JAR, et la bdd ne doit pas reposer sur un file system (il faut que ce soit du tout JAVA si vous voyez ce que j'essaye pénoblement de dire).
 
Si hsqldb permet de faire ca, c'est déjà un bon point :-)
 
 
Maintenant, voici en gros à quoi ressemble ma structure actuelle (non codée, mais dans ma tête) :
 

 
On voit donc qu'il y a au plus une imbrication de 2 HashMap (ou ArrayList/HashMap).
Bon, comptons en 3 au cas où j'ajoute des trucs.
(si vous avez peur de ne pas comprendre ce que je dis, n'hésitez pas à me demander des précisions, c'est important)
 
On peut donc voir que la sdd n'a rien d'exceptionnelle, il n'y a pas des masses de tables, c'est pour ca qu'une bdd me semble un peu "démesurée".
 
 
Maintenant, si vous pensez qu'en temps processeur / mémoire ce sera beaucoup plus efficace, moi je suis partant !
J'attends donc votre verdict définitif pour partir là dessus.
 
Merci !
 

Personne ?

 
petite question conne, le flux XML contient toute ta bibliothèque ? (tous les livres ?)
 
 
 

pourquoi ? absence de disque dur ou disque dur trop petit ?  
 
 

 
Ben en fait il me paraitrait normal que t'es déjà 4 classes (livre, auteur, genre, editeur) ... et puis c'est pas parce qu'il y a peu de tables qu'il faut éviter la D.B. ce qui compte c'est qu'elle aura beaucoup d'infos. à stocker.  
Il me paraitrait un peu plus normal qu'un flux XML d'UN livre soit scruté au moment où l'utilisateur demande des infos. dessus.
Dans ce cas t'a effectivement pas besoin de D.B. mais si en début de journée tu veux stocker tous les livres alors là je vois pas comment tu pourras te passer d'une D.B. à part te compliquer la vie ...

 
Il n'y a pas un unique flux mais plusieurs flux venant de plusieurs serveurs. Le rôle (entre autres) de mon programme est d'agréger ces flux afin de donner une visibilité globale à l'utilisateur.
 

 
Mon programme se trouvera sur une passerelle domestique (type XXXBox mais en plus costaud). Une des contraintes de cette passerelle est de ne pas  enregistrer d'informations. C'est une contrainte que l'on me donne, après je ne peux pas te dire si techniquement c'est une bonne idée ou non :-)
 
 

 
Alors le problème, c'est que lorsque l'utilisateur choisis le dossier "Victor Hugo" (depuis son interface) la passerelle doit chercher sur tous les serveurs tous les livres ayant pour auteur Victor Hugo. C'est un traitement qui est trop long pour être effectué à chaque requête (il faut parser le flux de milliers de livres...). Donc nous avons décidé de faire ce tri "à l'avance" (au démarrage) et en temps réel (les livres évoluent en temps réel et l'on scrute ces modifications puis on met à jour notre base présente sur la passerelle... enfin dans la théorie puisque c'est ce que je dois réaliser).
 
Mon but était donc de savoir ce qui était le plus approprié comme sdd. J'avais définis ce qui me semblait le plus logique comme architecture (sauvegarde des données brutes dans un coin, et mise en place d'un arbre de références pour une navigation plus rapide de l'utilisateur parmis le contenu). Je voulais savoir quelles étaient les classes Java les plus pertinentes et comment agencer ces classes pour sauvergarder mes infos et l'on m'a rediriger vers une BDD pure Java.
 
Toi tu me dis que je n'en ai pas "besoin" mais tu me conseils quand même son utilisation. Effectivement, je n'aurai pas beaucoup de tables, mais ces tables seront bien remplies comme tu le dis. Maintenant, je sais pas si ce sera plus efficace...
 
Par contre, la DataBase me permettra peut être de gérer plus facilement (efficacement ?) la consistance de ma base au niveau du lien "Livre - ses références dans mes tables de références", notamment quand je supprimerai des livres, ou que je modifierai leur éditeur (ce qui entraine la suppression d'une référence dans la table éditeur X et la création d'une référence dans la table éditeur Y), etc....
 
 
La seule chose qui me pose problème, c'est que je me demande pourquoi quelque chose d'écrit en pure Java sera plus efficace qu'une sdd que je ferai à la main (sans aucune vantardise, on ne peut pas dire que je soit trés compétent en prog, c'est donc une simple question).
 
Voilà ! Si il y a d'autres avis ou des réponses à mes questions, je suis toujours preneur !  

... et les stocker dans sa "mémoire" ? donc il te faut une BDD car rien que dans ton exemple il y a une quarantaine d'ouvrages ... il te faut donc quelquechose d'approprié pour stocker l'info. : BDD ET filesystem ...  
T'auras beau retourner le problème dans tous les sens ...  
 

Parce que tu cherches à optimiser le stockage des données et c'est pas pertinent au niveau propreté de conception et évolution. Tu pourras pas faire des miracles, tu vas essayer de faire tenir 40 ouvrages en mémoire vive et qu'il y aura plusieurs consultations à la fois tu vas avoir quelques soucis ... La BDD te permets de faire une architecture cohérente ... j'ai l'impression que tu veux d'emblée faire des raccourcis dans cette architecture --> spa une bonne idée.  
Globalement on t'as tous répondu "BDD", car tu te casses la tête pour rien ...  
 

 
non, je te donne un exemple d'utilisation où tu n'en aurais pas besoin, mais dans ton cas je vois pas comment tu peux éviter.  
 

ben ouais ... tout ça se fait tout seul depuis des décennies.  
 

 
Je me suis peut être pas assez plongé dans le problème mais admettons tu trouves une solution spécifique pour optimiser le stockage, dès qu'on te demandera une modif. ou une évolution ça va devenir l'enfer pour toi, ton temps de développement sera long ... et ça serai pour ta gueule.  
Tu nous a filé un diagramme (arbre), qui décrit une manière de faire une recherche, mais ça m'étonnerai que les besoins s'arrêtent à cette manière de faire une recherche. Donc tu vas pondre une archi. Java pour optimiser cette manière de recherche et dans deux jours on te demandera d'implémenter une recherche d'après d'autres critères ...

Ok ok, j'ai bien compris.
 
Je pense effectivement maintenant que la DB semble plus approriée. Je vais voir ca et je pense que je vais tenter de faire un développement parralèle avec une solution "maison". Je m'embète peut être pour rien, mais ca me permettra de comparer et d'être sûr.
 
Merci à tous ceux qui m'ont répondu, et si vous avez d'autres remarques, n'hésitez pas, je suis là pour apprendre.

Je reviens avec un lot de questions :
 
Je suis en train de me renseigner sur les bdd "embarquables" comme hsqldb (qui semble pas trop mal cotée). Avez vous d'autres bdd qu'hsqldb à me conseiller ?
 
Sinon il m'est tout d'un coup venu à l'esprit que le résultat de mon parsing XML, je le mettai dans un objet Java (contenant plusieurs attributs, etc...).
Or, en face j'aurai une bdd relationnelle. A ma connaissance, JDBC est juste une interface entre le monde JAVA et le monde SQL. Il ne va pas traduire mes objets en belles tables relationnelles.
Mais là, je me suis souvenu que j'avais rapidement vu Hibernate en cours. Je n'ai plus ça sous la main, donc j'ai fait un tour sur le net, et cela semble plutôt allez dans mon sens, Hibernate permettrait de faire l'interface entre mes objets Java et JDBC. (J'aurai donc "juste" à dire que je voudrai placer tel Objet là, comme un champ relationnel classique, et Hibernate ferait la traduction à ma place ?).
 
Bon, c'est caricatural, je crois qu'Hibernate fait plus que cela, mais en gros, ce serait jouable comme ca ?
 
Merci !

up du midi  

et ouais encore moi    
 
Je suis loin de connaître le nom des outils qu'il te faut, mais par exemple tu cites hibernate et il fait le mapping-objet me semble-t-il. Ce qui fait que tu accédes à ta BDD comme si c'était des objets ... je trouve ça très bien. Ca évite d'avoir des tas de "Select * from " + nomTable + " where " + nomAttribut ... tous moches dans ton code.  
 
 

et prevayler ?
 
( http://www.prevayler.org/wiki.jsp )

 
Salut.
 
Comme tu dis que tu n'as besoin d'aucune persistence, je ne comprends pourquoi tu aurais besoin d'une base de données quelconque. Les bases de données sont utilisées par définition pour la persistence des données. Les SGBD en mémoire ont assez peu d'usages. A ma connaissance, surtout pour les tests d'une appli utilisant une "vraie" base de données parce que c'est pénible de faire les tests sur la base sur disque (faut tout nettoyer après un test).
 
Il n'y a aucun avantage ni en utilisation mémoire, ni en rapidité d'accès aux données, à utiliser du SQL en mémoire. Sans parler d'Hibernate... Le temps que tu configures proprement hsqldb et Hibernate (sans aucun besoin !), tu auras pu coder 5 fois les routines de construction du graphe d'objet, de consultation, de mise à jour et de suppressions. Et de toutes façons si tu utilises Hibernate il faudra quand même que tu conçoives le graphe d'objets, donc tu es revenu au point de départ mais en pire...
 
Question : y-a-t-il un critère unique pour référencer un livre (ou un "objet" ), genre le titre ou le numéro ISBN ?  
 
Si oui :  
 
1) 1 classe Objet qui implémente l'interface Java Comparable, en comparant directement par le critère ci-dessus, appelons-le X. Comme ça, tu peux ranger tes objets dans des SortedSet. Tu mets aussi dans l'Objet une List (ArrayList devrait faire l'affaire) pour chaque possibilité de classer. Par exemple, la liste des auteurs du livre, la liste des genres auquel appartient le livre, etc. Si pour chaque possibilité tu n'as le droit qu'à un choix (1 seul genre par exemple), c'est encore plus simple, tu ne mets pas une liste mais un simple champ.
 
2) 1 classe "SuperContainer" qui contient autant de HashMap que de possibilités de classer (Genre, Auteur, ...). Dans la HashMap pour les auteurs, tu feras par exemple l'association "Emile Zola" --> HashMap des livres qui ont Emile Zola pour auteur.  
 
HashMap [auteur --> HashMap ["critère x" --> livre] ]
 
3) 1 classe Bibliothèque qui contient un HashMap HashMap ["critère x" --> livre] de tous les livres.
 
Cela me paraît à peu près bon, mais il faudrait avoir les spécifs exactes des actions possibles de l'utilisateur pour vérifier.
 
(édité pour enlever un gros délire sur les SortedSet)

Et bien écoute, j'avais préparé un petit topo sur la nouvelle approche (en passant par hsqldb) et l'on m'a répondu quelque chose de similaire...
Donc je vais faire ma structure "à la mano", c'est pourquoi ta réponse m'intéresse.
 
Sinon pour répondre à ta question : oui il y a un critère unique pour référencer mes objets (qui ne sont pas que des livres, je n'ai pas tout détaillé afin de rendre tout un peu plus compréhensible). Par contre je dois bien avouer que je ne comprends pas trop ta réponse. Surtout le point 1).
 
Le point 2) me parle plus, puisque je suis parti sur cette structure au niveau de ma "table de références" (ce qui donne par exemple :  
HashMapAuteur[(......), (Zola, HashMapZola[(......), (identifiantUniqueDUnLivre, référenceVersLeLivreLAssomoir]), (....)]), (....)]
 
Le point 3), je n'en comprends pas l'utilité ??
 
 
Ma structure actuelle se compose d'une classe Bibliothèque, qui contient une HashMap de tous les livres ( HashMapLivres[(....),(identifiantUniqueDUnLivre,référenceVersUnLivre),(...)] ) de la table de références présentée ci dessus, et d'objets Livres qui contiennent une ArrayList de couples (référenceVersHashTable,clé) de toutes les références pointant vers cet objet Livre.
 
Exemple :
 
La table de référence (détail) :
 
HashMapAuteur[(......), (Zola, HashMapZola[(......), (idUniqueAssomoir, référenceVersLeLivreLAssomoir]), (....)]), (....)]
 
HashMapGenre[(......), (RomanNaturaliste, HashMapRomanNaturaliste[(......), (idUniqueAssomoir, référenceVersLeLivreLAssomoir]), (....)]), (....)]
 
L'objet Livre Assomoir associé possède donc l'ArrayList suivante ( ArrayList[[index0],[index1],[index2],[index3],...]:
 
ArrayListDesReferencesPointantSurMoi[[référenceVersHashMapZola],[idUniqueAssomoir],[référenceVersHashMapRomanNaturaliste],[idUniqueAssomoir],[]]
 
Je marque "idUniqueAssomoir" au cas où l'on décide que l'identifiant n'est plus unique, mais sinon cette ArrayList ne sera composée que de références vers les Hashmap contenant des références vers un Livre. A partir de l'un on trouve l'autre et vice versa.

 
Ma dernière réponse était nulle au possible, excuse je me suis dit "très simple" et j'ai écrit trop vite sans prendre le temps de mettre un peu sur le papier.
 
On a des Livres qui ont un identifiant unique (on va dire n°ISBN). On veut pouvoir :
1) Ajouter un livre ;
2) Retirer un livre ;
3) Modifier un livre ;
4) (Evidemment) Accéder à un livre ;
5) Connaître tous les livres qui répondent à un critère. Les types de critères (Auteur, Genre, ...) sont prédéfinis.
 
Une HashMap [ ISBN --> Livre ]  contient les livres.
 
Pour chaque type de critère, une HashMap permettant de retrouver tous les livres répondant à une valeur du critère. Pour chaque valeur du critère, l'ensemble des livres est rangé dans un HashMap.
 
Exemple pour les auteurs : HashMap[ ( "Zola" -> HashMap[ ISBN --> Livre], ...)
 
Dans chaque Livre, une liste par type de critère. Dans cette liste, on met l'ensemble des valeurs du critère auxquelles le livre répond.
 
Exemple :
Livre ( ISBN = 1, Titre = "L'assomoir", List auteurs ["Zola" ], List genre ["roman XIXè", "roman naturaliste", ...], etc etc).
 
Ensuite par exemple pour supprimer un livre :
a) Trouver le livre dans la HashMap de tous les livres
a) Pour chaque List de valeurs de critères dans le livre, parcourir toutes les valeurs.  
b) Pour chaque valeur, accéder dans la HashMap du critère à la HashMap de la valeur du critère et y supprimer le couple (ISBN, Livre)
c) Supprimer le couple (ISBN --> Livre)
 
Par exemple pour supprimer l'Assomoir (plus précisément pour supprimer le livre dont l'ISBN vaut 1) :
* Dans la HashMap de tous les livres, je trouve l'objet Livre correspondant ;
* Pour les auteurs, y'en a qu'un, "Zola". Je vais dans la HashMap des auteurs, je récupère la valeur associée à la clé "Zola". Cette valeur est une HashMap, dans laquelle je retire le couple (ISBN = 1, Livre(L'assomoir) ;
Pour les genres, idem.
Pour les éditeurs idem.
* Je supprime le couple [ISBN = 1, Livre(L'assomoir)] de la HashMap de tous les livres.

Ok merci !
 
Désolé pour le temps de réponse, j'ai eu d'autres choses plus urgentes...
 
Au final, ce que je vais faire est trés proche de ce que tu me dis... et de ce que je proposais au début  
 
Merci à tous ceux qui ont participé, j'ai appris quelques petits trucs au passage :-)