Choix de système de données (en français cette fois !)
3 réponses
William A.
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données en
MFC.
En gros mon application consiste en une TreeView liée à une ListView (comme
l'explorateur windows). L'utilisateur crée des dossiers virtuels dans la
treeview et place des fichiers dans ces dossiers à l'aide de la listview.
Comment puis-je sauvegarder toutes les données de ma treeview (structures de
l'arbre et liste des fichiers avec leur infos ...) ?
Comme l'arbre risque d'être très gros je ne pense pas que je puisse tout
charger en mémoire.
Quelle est la meilleure façon de sauvegarder ces données et de pouvoir les
consulter rapidement pendant l'éxécution (lorsqu'un utilisateur selectionne
un dossier -> affiche son contenu dans la listview).
J'avais pensé utiliser une base de donnée ce qui me permettrait de lancer
des instructions SQL simple pour pouvoir trouver un fichier, faire des tris,
ajouter, supprimer facilement et rapidement.
Qu'en pensez vous ?
Merci BEAUCOUP !
Will
__________________________________________________________________ Goulou
ICQ#: 111148586 Current ICQ status: + More ways to contact me
__________________________________________________________________
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Benoit Dejean
Le Fri, 03 Oct 2003 00:04:29 +0200, William A. a écrit :
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données en MFC. En gros mon application consiste en une TreeView liée à une ListView (comme l'explorateur windows)
essaye encore http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/#generalites news:fr.comp.ms-windows.programmation
:oD
Le Fri, 03 Oct 2003 00:04:29 +0200, William A. a écrit :
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données
en MFC.
En gros mon application consiste en une TreeView liée à une ListView
(comme l'explorateur windows)
essaye encore
http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/#generalites
news:fr.comp.ms-windows.programmation
Le Fri, 03 Oct 2003 00:04:29 +0200, William A. a écrit :
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données en MFC. En gros mon application consiste en une TreeView liée à une ListView (comme l'explorateur windows)
essaye encore http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/#generalites news:fr.comp.ms-windows.programmation
:oD
Samuel Krempp
je crois que tu pourrais formuler ta question sans parler de MFC, de treeView, ou de listview. je ne connais rien de ces choses, je te réponds à partir de ce que j'ai compris sur le fond du problème : en chaque noeud d'un arbre, il y a un objet liste associée, et le problème est de sauver le tout.
1° solution : définir une structure sérialisable à-la template<class C> Tree, puis stocker arborescence ET objets listes (notons Objet ce type liste) dans un Tree<Objet>, qu'il suffit de sérialiser. Si l'ensemble total des objets ne tient pas en mémoire, il faut ajouter un niveau d'indirection, et concevoir la classe Objet de la manière qu'il faut pour accèder à cette liste hors mémoire (un nom de fichier, ou table SQL..)
2° solution : lier l'arboresence à l'ordre des objets et les gérer séparément : faire en sorte que l'arborescence utilisée fournit à chaque noeud un identificateur unique noeud.id() (un numéro de noeud, ou un chemin..) de type Id_type (int, ou string, ..), A. parcourir l'arborescence, et à chaque noeud, insérer dans une map<Id_type, Objet> l'objet liste associé, avec pour clef noeud.id() B. sauver l'arborescence C. sauver le map. Encore une fois, pour éviter d'avoir à tout avoir en mémoire en meme temps, il suffit d'ajouter un niveau d'indirection et faire une classe Objet qui accède à un fichier contenant l'objet, au lieu d'être l'objet lui même.
et la restauration ne pose pas de problème.
-- Sam
je crois que tu pourrais formuler ta question sans parler de MFC, de
treeView, ou de listview.
je ne connais rien de ces choses, je te réponds à partir de ce que j'ai
compris sur le fond du problème :
en chaque noeud d'un arbre, il y a un objet liste associée, et le problème
est de sauver le tout.
1° solution : définir une structure sérialisable à-la
template<class C> Tree, puis stocker arborescence ET objets listes (notons
Objet ce type liste) dans un Tree<Objet>, qu'il suffit de sérialiser.
Si l'ensemble total des objets ne tient pas en mémoire, il faut ajouter un
niveau d'indirection, et concevoir la classe Objet de la manière qu'il faut
pour accèder à cette liste hors mémoire (un nom de fichier, ou table SQL..)
2° solution :
lier l'arboresence à l'ordre des objets et les gérer séparément : faire en
sorte que l'arborescence utilisée fournit à chaque noeud un identificateur
unique noeud.id() (un numéro de noeud, ou un chemin..) de type Id_type
(int, ou string, ..),
A. parcourir l'arborescence, et à chaque noeud, insérer dans une
map<Id_type, Objet> l'objet liste associé, avec pour clef noeud.id()
B. sauver l'arborescence
C. sauver le map.
Encore une fois, pour éviter d'avoir à tout avoir en mémoire en meme temps,
il suffit d'ajouter un niveau d'indirection et faire une classe Objet qui
accède à un fichier contenant l'objet, au lieu d'être l'objet lui même.
je crois que tu pourrais formuler ta question sans parler de MFC, de treeView, ou de listview. je ne connais rien de ces choses, je te réponds à partir de ce que j'ai compris sur le fond du problème : en chaque noeud d'un arbre, il y a un objet liste associée, et le problème est de sauver le tout.
1° solution : définir une structure sérialisable à-la template<class C> Tree, puis stocker arborescence ET objets listes (notons Objet ce type liste) dans un Tree<Objet>, qu'il suffit de sérialiser. Si l'ensemble total des objets ne tient pas en mémoire, il faut ajouter un niveau d'indirection, et concevoir la classe Objet de la manière qu'il faut pour accèder à cette liste hors mémoire (un nom de fichier, ou table SQL..)
2° solution : lier l'arboresence à l'ordre des objets et les gérer séparément : faire en sorte que l'arborescence utilisée fournit à chaque noeud un identificateur unique noeud.id() (un numéro de noeud, ou un chemin..) de type Id_type (int, ou string, ..), A. parcourir l'arborescence, et à chaque noeud, insérer dans une map<Id_type, Objet> l'objet liste associé, avec pour clef noeud.id() B. sauver l'arborescence C. sauver le map. Encore une fois, pour éviter d'avoir à tout avoir en mémoire en meme temps, il suffit d'ajouter un niveau d'indirection et faire une classe Objet qui accède à un fichier contenant l'objet, au lieu d'être l'objet lui même.
et la restauration ne pose pas de problème.
-- Sam
Patrick \Zener\ BRUNET
Bonjour.
On va abstraire un peu pour ne pas être HS.
On a typiquement une structure de données arborescentes, couplée à une interface graphique. De plus, comme c'est souvent le cas et pas seulement pour des raisons de taille, les noeuds de la structure de données ne peuvent pas conserver tout leur contenu en mémoire, et donc contiennent une abstraction qui désigne la donnée effective (par exemple, si on représente un système de fichiers, la "donnée" reste bien hors mémoire).
Il est essentiel de séparer la structure de données de l'interface graphique : - d'une part parce que les objets de l'interface graphique ne peuvent pas contenir tout ce qu'on veut mettre dans un noeud de données, - d'autre part pour garder son indépendance vis à vis de l'IHM, dont le code est souvent géré salement par un "Wizard", et aussi que l'on peut espérer substituer un jour.
Donc il est pertinent de créer une classe "noeud" pouvant être assemblée de manière arborescente, et éventuellement des classes dérivées pour les différentes sortes de noeuds, noeuds dans lesquels on définit : - l'ensemble des informations permettant d'accéder à la "donnée" effective, - des informations minimales de résumé utilisables efficacement par le preview de l'IHM, - un ensemble de fonctions de chirurgie de l'arbre et de navigation, - les primitives permettant d'opérer les transformations équivalentes sur l'arbre IHM.
Généralement, l'arbre de l'IHM offre la possibilité de stocker une information "user" (de la taille d'un pointeur) dans chaque noeud, et par ailleurs chaque noeud est doté d'un "handle" invariable. Cela permet de lier bidirectionnellement chaque noeud IHM à un noeud de la structure.
Ensuite, dans le code d'IHM, on va traiter toutes les opérations possibles sur l'arbre IHM en les exprimant à partir des fonctions de chirurgie de l'arbre de données. Il est également possible d'inclure dans la procédure des fonctions de validation (par exemple dans un drag'n'drop, interrogation des cibles survolées pour acceptabilité de l'item en cours de drag).
********************************** Ainsi on aboutit à une bonne séparation entre l'intelligence de la structure de données, et une structure IHM équivalente qui ne fait que lui transmettre des requêtes et en refléter le résultat. **********************************
Pour ce qui est de la visu du noeud sélectionné dans la seconde vue de l'IHM, typiquement la fenêtre qui porte les deux vues est notifiée lorsque le noeud sélectionné change, et donc de même le noeud de la structure nouvellement sélectionné va être sollicité par la vue de visu pour s'y représenter, au moyen d'une fonction de résumé spécifique qu'il fournit. Si l'accès à la donnée "effective" est coûteux, il peut être important de ne pas le faire immédiatement à chaque changement de sélection dans l'arbre, sinon ça va ramer. D'où l'importance d'un résumé.
Enfin, un point important est celui de la répercussion sur la structure de données "effective" des modifications effectuées sur sa représentation en mémoire. Il n'est pas forcément pertinent de les exécuter au fur et à mesure, surtout si elles sont coûteuses. Dans une appli que j'ai écrite, j'ai préféré prévoir un tableau de "ordres de modifications à effectuer", ces enregistrements étant enfilés au fur et à mesure des actions sur la structure mémoire, puis exécutées en chaîne au moment opportun. Cela introduit une sorte de double-pensée dans la gestion de la structure mémoire (l'état visible n'est pas encore répercuté), mais ça reste souvent gérable.
Tout ceci est réalisable facilement avec ce que permettent les objets d'IHM que je connais, notamment le CTreeView des MFC.
Hope It Helps.
Patrick "Zener" Brunet
"William A." a écrit dans le message news: 3f7ca196$0$20642$
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données en MFC. En gros mon application consiste en une TreeView liée à une ListView (comme
l'explorateur windows). L'utilisateur crée des dossiers virtuels dans la treeview et place des fichiers dans ces dossiers à l'aide de la listview.
Comment puis-je sauvegarder toutes les données de ma treeview (structures de
l'arbre et liste des fichiers avec leur infos ...) ? Comme l'arbre risque d'être très gros je ne pense pas que je puisse tout charger en mémoire.
Quelle est la meilleure façon de sauvegarder ces données et de pouvoir les consulter rapidement pendant l'éxécution (lorsqu'un utilisateur selectionne
un dossier -> affiche son contenu dans la listview).
J'avais pensé utiliser une base de donnée ce qui me permettrait de lancer des instructions SQL simple pour pouvoir trouver un fichier, faire des tris,
ajouter, supprimer facilement et rapidement.
Qu'en pensez vous ?
Merci BEAUCOUP !
Will
__________________________________________________________________ Goulou ICQ#: 111148586 Current ICQ status: + More ways to contact me __________________________________________________________________
Bonjour.
On va abstraire un peu pour ne pas être HS.
On a typiquement une structure de données arborescentes, couplée à une
interface graphique. De plus, comme c'est souvent le cas et pas seulement
pour des raisons de taille, les noeuds de la structure de données ne peuvent
pas conserver tout leur contenu en mémoire, et donc contiennent une
abstraction qui désigne la donnée effective (par exemple, si on représente
un système de fichiers, la "donnée" reste bien hors mémoire).
Il est essentiel de séparer la structure de données de l'interface graphique
:
- d'une part parce que les objets de l'interface graphique ne peuvent pas
contenir tout ce qu'on veut mettre dans un noeud de données,
- d'autre part pour garder son indépendance vis à vis de l'IHM, dont le code
est souvent géré salement par un "Wizard", et aussi que l'on peut espérer
substituer un jour.
Donc il est pertinent de créer une classe "noeud" pouvant être assemblée de
manière arborescente, et éventuellement des classes dérivées pour les
différentes sortes de noeuds, noeuds dans lesquels on définit :
- l'ensemble des informations permettant d'accéder à la "donnée" effective,
- des informations minimales de résumé utilisables efficacement par le
preview de l'IHM,
- un ensemble de fonctions de chirurgie de l'arbre et de navigation,
- les primitives permettant d'opérer les transformations équivalentes sur
l'arbre IHM.
Généralement, l'arbre de l'IHM offre la possibilité de stocker une
information "user" (de la taille d'un pointeur) dans chaque noeud, et par
ailleurs chaque noeud est doté d'un "handle" invariable. Cela permet de lier
bidirectionnellement chaque noeud IHM à un noeud de la structure.
Ensuite, dans le code d'IHM, on va traiter toutes les opérations possibles
sur l'arbre IHM en les exprimant à partir des fonctions de chirurgie de
l'arbre de données. Il est également possible d'inclure dans la procédure
des fonctions de validation (par exemple dans un drag'n'drop, interrogation
des cibles survolées pour acceptabilité de l'item en cours de drag).
**********************************
Ainsi on aboutit à une bonne séparation entre l'intelligence de la structure
de données, et une structure IHM équivalente qui ne fait que lui transmettre
des requêtes et en refléter le résultat.
**********************************
Pour ce qui est de la visu du noeud sélectionné dans la seconde vue de
l'IHM, typiquement la fenêtre qui porte les deux vues est notifiée lorsque
le noeud sélectionné change, et donc de même le noeud de la structure
nouvellement sélectionné va être sollicité par la vue de visu pour s'y
représenter, au moyen d'une fonction de résumé spécifique qu'il fournit. Si
l'accès à la donnée "effective" est coûteux, il peut être important de ne
pas le faire immédiatement à chaque changement de sélection dans l'arbre,
sinon ça va ramer. D'où l'importance d'un résumé.
Enfin, un point important est celui de la répercussion sur la structure de
données "effective" des modifications effectuées sur sa représentation en
mémoire. Il n'est pas forcément pertinent de les exécuter au fur et à
mesure, surtout si elles sont coûteuses. Dans une appli que j'ai écrite,
j'ai préféré prévoir un tableau de "ordres de modifications à effectuer",
ces enregistrements étant enfilés au fur et à mesure des actions sur la
structure mémoire, puis exécutées en chaîne au moment opportun. Cela
introduit une sorte de double-pensée dans la gestion de la structure mémoire
(l'état visible n'est pas encore répercuté), mais ça reste souvent gérable.
Tout ceci est réalisable facilement avec ce que permettent les objets d'IHM
que je connais, notamment le CTreeView des MFC.
Hope It Helps.
Patrick "Zener" Brunet
"William A." <watzel@free.fr> a écrit dans le message news:
3f7ca196$0$20642$626a54ce@news.free.fr...
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données en
MFC.
En gros mon application consiste en une TreeView liée à une ListView
(comme
l'explorateur windows). L'utilisateur crée des dossiers virtuels dans la
treeview et place des fichiers dans ces dossiers à l'aide de la listview.
Comment puis-je sauvegarder toutes les données de ma treeview (structures
de
l'arbre et liste des fichiers avec leur infos ...) ?
Comme l'arbre risque d'être très gros je ne pense pas que je puisse tout
charger en mémoire.
Quelle est la meilleure façon de sauvegarder ces données et de pouvoir les
consulter rapidement pendant l'éxécution (lorsqu'un utilisateur
selectionne
un dossier -> affiche son contenu dans la listview).
J'avais pensé utiliser une base de donnée ce qui me permettrait de lancer
des instructions SQL simple pour pouvoir trouver un fichier, faire des
tris,
ajouter, supprimer facilement et rapidement.
Qu'en pensez vous ?
Merci BEAUCOUP !
Will
__________________________________________________________________ Goulou
ICQ#: 111148586 Current ICQ status: + More ways to contact me
__________________________________________________________________
On a typiquement une structure de données arborescentes, couplée à une interface graphique. De plus, comme c'est souvent le cas et pas seulement pour des raisons de taille, les noeuds de la structure de données ne peuvent pas conserver tout leur contenu en mémoire, et donc contiennent une abstraction qui désigne la donnée effective (par exemple, si on représente un système de fichiers, la "donnée" reste bien hors mémoire).
Il est essentiel de séparer la structure de données de l'interface graphique : - d'une part parce que les objets de l'interface graphique ne peuvent pas contenir tout ce qu'on veut mettre dans un noeud de données, - d'autre part pour garder son indépendance vis à vis de l'IHM, dont le code est souvent géré salement par un "Wizard", et aussi que l'on peut espérer substituer un jour.
Donc il est pertinent de créer une classe "noeud" pouvant être assemblée de manière arborescente, et éventuellement des classes dérivées pour les différentes sortes de noeuds, noeuds dans lesquels on définit : - l'ensemble des informations permettant d'accéder à la "donnée" effective, - des informations minimales de résumé utilisables efficacement par le preview de l'IHM, - un ensemble de fonctions de chirurgie de l'arbre et de navigation, - les primitives permettant d'opérer les transformations équivalentes sur l'arbre IHM.
Généralement, l'arbre de l'IHM offre la possibilité de stocker une information "user" (de la taille d'un pointeur) dans chaque noeud, et par ailleurs chaque noeud est doté d'un "handle" invariable. Cela permet de lier bidirectionnellement chaque noeud IHM à un noeud de la structure.
Ensuite, dans le code d'IHM, on va traiter toutes les opérations possibles sur l'arbre IHM en les exprimant à partir des fonctions de chirurgie de l'arbre de données. Il est également possible d'inclure dans la procédure des fonctions de validation (par exemple dans un drag'n'drop, interrogation des cibles survolées pour acceptabilité de l'item en cours de drag).
********************************** Ainsi on aboutit à une bonne séparation entre l'intelligence de la structure de données, et une structure IHM équivalente qui ne fait que lui transmettre des requêtes et en refléter le résultat. **********************************
Pour ce qui est de la visu du noeud sélectionné dans la seconde vue de l'IHM, typiquement la fenêtre qui porte les deux vues est notifiée lorsque le noeud sélectionné change, et donc de même le noeud de la structure nouvellement sélectionné va être sollicité par la vue de visu pour s'y représenter, au moyen d'une fonction de résumé spécifique qu'il fournit. Si l'accès à la donnée "effective" est coûteux, il peut être important de ne pas le faire immédiatement à chaque changement de sélection dans l'arbre, sinon ça va ramer. D'où l'importance d'un résumé.
Enfin, un point important est celui de la répercussion sur la structure de données "effective" des modifications effectuées sur sa représentation en mémoire. Il n'est pas forcément pertinent de les exécuter au fur et à mesure, surtout si elles sont coûteuses. Dans une appli que j'ai écrite, j'ai préféré prévoir un tableau de "ordres de modifications à effectuer", ces enregistrements étant enfilés au fur et à mesure des actions sur la structure mémoire, puis exécutées en chaîne au moment opportun. Cela introduit une sorte de double-pensée dans la gestion de la structure mémoire (l'état visible n'est pas encore répercuté), mais ça reste souvent gérable.
Tout ceci est réalisable facilement avec ce que permettent les objets d'IHM que je connais, notamment le CTreeView des MFC.
Hope It Helps.
Patrick "Zener" Brunet
"William A." a écrit dans le message news: 3f7ca196$0$20642$
Salut,
Je suis étudiant et je développe un logiciel de sauvegarde de données en MFC. En gros mon application consiste en une TreeView liée à une ListView (comme
l'explorateur windows). L'utilisateur crée des dossiers virtuels dans la treeview et place des fichiers dans ces dossiers à l'aide de la listview.
Comment puis-je sauvegarder toutes les données de ma treeview (structures de
l'arbre et liste des fichiers avec leur infos ...) ? Comme l'arbre risque d'être très gros je ne pense pas que je puisse tout charger en mémoire.
Quelle est la meilleure façon de sauvegarder ces données et de pouvoir les consulter rapidement pendant l'éxécution (lorsqu'un utilisateur selectionne
un dossier -> affiche son contenu dans la listview).
J'avais pensé utiliser une base de donnée ce qui me permettrait de lancer des instructions SQL simple pour pouvoir trouver un fichier, faire des tris,
ajouter, supprimer facilement et rapidement.
Qu'en pensez vous ?
Merci BEAUCOUP !
Will
__________________________________________________________________ Goulou ICQ#: 111148586 Current ICQ status: + More ways to contact me __________________________________________________________________
