Bonjour,
 
Je realise actuelement une base de donnée au sein d'un stage, et suis confronté a un probleme (pour moi avec mon niveau de debutant en BDD).  
 
Je dois stoker regulierement des infos provenant de diverses sources, et certaines informations se regroupent par bloc, qui se regrouppent par bloc .... Et je ne peut connaitre a l'avance le nombre de bloc en cascade auquel j'aurai a faire. J'ai donc pensé a une structure recursive ou chaque bloc possede une cle etrangere vers un bloc, et ainsi de suite. Mais cela me parait bizarre de realiser de la recursion dans une BDD.  
 
Le but etait aussi que le nombre de bloc est tres important, et donc utiliser beaucoup de table va tres vite prendre beaucoup de place. Je n'arrive pas a estimer le rapport taille.place, et savoir quel serait la solution la plus pertinente.  
 
Avez vous deja connu des problemes de ce type ?
 
Makko
 
Ps: bonjour a tous, c'est mon premier message sur ce forum

donne plus de précisions. A priori, je pencherais plus pour une erreur de conception.

 
Le but de ma base est de modeliser des infos qui pourraient globalement s'apparenter a des graphes. Sauf qu'il y aurait un petit milier de noeud par graphe. Donc pour pouvoir les traiter par la suite, les noeuds avec leurs informations propres sont regroupés par groupe ( qui eux meme contienent des informations, en particulier le sequencement ), qui eux meme peuvent se regrouper par groupe (et ainsi de suite) ... J'etais parti sur deux table, une de base avec tous les noeuds et les informations relatives, et une autre qui definit les differents blocs. Mais je ne peut savoir a l'avance le nombre de bloc. Chaque bloc est codé dans la source.
 
J'avais laissé tomber la table intermediaire, car la table va grossir extremement vite et cela me faisait peur au niveau du temps d'acces. (cette table grossira de 8000 entree par jour). Mais c'est peut etre la l'erreur ?
 
En esperant avoir ete plus clair sur mon probleme .....

bah c'est simple; soit tu sais catégoriser à l'avance les infos que tu as dans tes noeuds, parce qu'elles sont reliées à un identifiant, et donc tu peux stocker ces infos dans des tables adhoc, soit ce sont des infos attachées au gré d'un outil, sans spécification particulière, et dans ce cas, tu n'a pas vraiment le choix, tu dois tout fourrer dans un champ (text par exemple).