Discussion :

[kurkaine]

Bonjour

Je n'ai pas encore débuté en XML, je fais une étude afin d'éviter d'utiliser une bd Access et rendre la bd de mon appli qui sera développé en C++ Builder pour windows portable. J'aimerai avoir votre avis afin de savoir si le XML dans mon cas est bien adapté car je n'ai pas trouvé d'aide sur les performances lors de la lecture d'un fichier.

Je vais décrire ci dessous toutes les imbrications de mes XML que je peux avoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
<media>...</media>
<objet>...</objet>
-----------------------------
// Je stocke la date, l'auteur, la durée, la taille, le chemin, un, grand commentaire, etc... ce genre d'information
<video_n>
          .....
          <objet>...</objet>
          <media>...</media>
</video_n>
 
<audio_n>
          .....
          <objet>...</objet>
          <media>...</media>
</audio_n>
 
<conseil_n>
          .....
</conseil_n>
-------------------------------
// Je peux avoir autant par FIGURE : 5 vidéo, 3 audio, 3 conseil. En plus je stoke
<Figure_n>
          <video_n>...</video_n>
          <video_j>...</video_j>
          <audio_x>...</audio_x>
</Figure_n>
 
-------------------------------
// Je peux avoir autant de Categorie que je veux contenant autant de figure que je veux
<Categorie_n>
          <Figure_n>...</Figure_n>
          <Figure_j>...</Figure_j>
          <Figure_x>...</Figure_x>
</Categorie_n>
 
-------------------------------
// Je peux avoir autant de Section que je veux contenant autant de Catégorie que je veux
<Section _n>
          <Categorie_n>...</Categorie_n>
          <Categorie_j>...</Categorie_j>
          <Categorie_x>...</Categorie_x>
</Section _n>

Voilà, en réalité je n'aurai pas l'infini de Section ou de Catégorie, je pense avoir 5 Sections avec 10 catégories par sections et 50 Figures par sections. Ce qui fait que mes fichiers XML vont être un peu (voir TRES) volumineux.

Mes questions sont:

- Est ce que XML est adapté pour ce type de gestions ?

- Est ce qu'il est préférable d'avoir 1 seul fichiers XML contenant toutes les données ou vaut mieux plusieurs fichiers XML (un pour stoker les vidéo, adio, conseil, un pour les Figures, un pour les Catégories, un pour les Sections)

- Est ce que je peux stocker pour les stoker seulement les id des vidéos par exemple (<figure> <video> video_id </video> </figure>) ou il vaut mieux stoker à chaque fois toutes les données ? Enfin je me fais comprendre


J'espère avoir été claire. Encore une fois, je n'ai pas encore débuté le XML, ayant travaillé avec des fichiers de descriptions simples dans mes programmes (C++ ou Php), j'aimerai être sur de mes choix

Merci d'avance pour d'éventuelles réponses.

[alain.couthures]

Communément, un fichier XML est chargé en mémoire pour pouvoir être exploité ensuite. C'est pourquoi il me semble plus pertinent de partir sur un fichier unique.
Cela dépend bien sûr de la taille de RAM disponible mais plusieurs dizaines de kilo octets ne posent, d'habitude, aucun problème.

Une fois en mémoire, un parcours d'arbre XML peut être très efficace. Pour moi qui est connu les bases de données hiérarchiques avant les bases de données relationnelles, on peut dire qu'un arbre XML est optimisé pour certains parcours alors qu'il ne l'est pas pour d'autres. Le principe relationnel est de mettre tout ce qui est de même nature dans autant de tables et de permettre des analyses transversales. Un exemple, en XML, les lignes d'une commande ne sont pas avec les lignes d'une autre commande mais avec la commande elle-même : c'est bien plus efficace d'aller chercher en mémoire une commande et ses lignes que dans une base de données, même si cette dernière a un cache mémoire.

En tout cas, il n'est pas recommandé d'y stocker des données binaires car il faut d'abord les convertir en base 64. Ca allourdit le fichier sans intérêt particulier. On préfèrera, bien sûr, mémoriser dans le XML ce qu'il faut pour aller chercher les données (nom de fichier, url,...)

[kurkaine]

Merci de ta réponse,

En fait, je ne stocke aucune donnée en binaire. Je stoke juste les chemins, des commentaires, des données qui seront affichées.

En gros tu me dis que

1. Si mon fichier fais 2méga, je ne vais pas saturer la mémoire d'un PC moderne,

2. Donc le XML serait bien adapté pour mon pb

3. Comme les données seront chargées en mémoires autant avoir un fichier

J'ai toutefois une dernière question :

Je vais stoker par exemple des informations que je représente comme il s'agissait d'une BD (je ne sais aps si on peut procéder de la meme façon pour du XML) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
info_audio
{
  id_fichier // UN ID UNIQUE
  date
  nom_auteur
  commentaire
  ...
}

Est ce que je peux l'utiliser de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Figure
{
  id_figure // Tjs un ID unique
  nom
  date
  id_info_audio  //!!! ICI JE STOKE L'ID DE MON FICHIER AUDIO définit plus haut, et donc je ne réécris pas plusieurs fois info_audio
}

En fait, c'est ce qu'on appelle des clés primaires, secondaires dans les SGBD. Ca me permet d'avoir une occurence de "info_audio", et donc tous les avantages (je modifie qu'une fois, gain en mémoire, etc.)

En XML, il est conseillé de procéder de la sorte ou non ?

Merci d'avance pour une future réponse.

[alain.couthures]

J'ai déjà exploité des fichiers de plusieurs Mo sur des PC pas très frais. C'est d'abord le parseur puis le moteur de transformation qui font la différence. Moi j'utilise le framework .Net 2.0 parce qu'il est gratuit et très efficace.

On peut effectivement utiliser un attribut "id" (ce nom, bien que non réservé, est, tout de même, consacré à cela...) pour permettre un accès rapide à une autre partie de l'arbre.

La sauvegarde d'un document XML suite à sa mise à jour est beaucoup plus problématique car, en standard, on ne peut qu'écrire l'ensemble du document sur fichier ce qui peut être un peu long si on doit le faire assez souvent.

[kurkaine]

Ok, merci pour tes renseignements. Je crois que je vais me mettre en XML.


En fait, pour éviter de tout réécrire lors de la sauvegarde, il serait plus pratique d'utiliser plusieurs fichiers XML alors ? Pour avoir moins d'informations à écrire. Mais je n'ai pas bien compris la problématique, même si le fichier est gros (>2mg), c'est si génant de tout réécrire à chaque fois ? Et puis, je ne comprends pas pourquoi tout réécrire ? Le machin qui gère l'XML (je ne sais aps comment le nommer, j'utiliserai un adon sous mon environnement de prog.) n'est pas capable d'écrire que les champs modifiés, c'est cela ?

[alain.couthures]

C'est bien le problème : le XML une fois chargé en mémoire est complètement déconnecté d'un fichier (car il peut venir d'un message, par exemple).

Le parcours et la transformation sont "faciles", même s'il faut penser autrement, mais la mise à jour ponctuelle est pénible. On utilise l'API DOM qui est plutôt lourde mais pas compliquée.

Si on veut que la sauvegarde sur fichier soit minimale, il faut découper en plusieurs fichiers en décidant que tel ou tel élément doit donner lieu à un sous-fichier plutôt que de rester dans le fichier de l'élément père. J'ai travaillé là-dessus sur mon projet OpenSource : un ensemble de fichiers est chargé sous la forme d'un seul document en mémoire avec des attributs indiquant où se font les découpes en fichiers. On retombe sur une problématique de base de données avec la notion de COMMIT lorsque l'on demande à ce que les fichiers soient mis à jour d'après le document en mémoire. J'ai pensé à cette mécanique pour des données de plusieurs dizaines de Mo considérant qu'il s'agit, tout de même, de se passer d'un moteur de base de données qui à lui seul va vite les prendre.