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.

[kurkaine]

Ok, les sauvegardes, c'est du caca.

Mais par contre, si j'ai des données dans plusieurs fichiers (ex: un fichier pour stocker les infos sur les médias vidéos et audios) un fichier pour les catégoriser (donc j'ai des id de médias et non les infos) ; les fichiers ne seront pas connectés automatiquement ? Je ne pourrais pas rechercher toute la structure d'un média à partir de son ID ? (genre une opération "SELECT * FROM media_audio WHERE id_media_audio = 2" )

En ce qui concerne les sauvegardes, ça veut dire que je charge en mémoire mes fichiers au démarrage, j'enregistre quand je quitte mon appli, mais les données qui ont été ajouté pendant l'ouverture du logiciel ne seront mis à jour dans mon arborescence XML ?

... Merci beaucoup pour ta patience.

[alain.couthures]

L'approche XML est orientée production de données et non pas traitement (je me comprends, je me comprends,...) : on produit une page (X)HTML (un formulaire le cas échéant), un document à imprimer, ... à partir d'un document XML.

La transformation XSL-T est le moyen majeur pour assurer cette production, quitte à la compléter d'un traitement automatique de conversion, par exemple pour générer un PDF. Il est possible dans une transformation XSL-T de faire appel à des données présentes ailleurs (sur fichier ou par requête HTTP simple) mais ces dernières seront rechargées à chaque fois. Le mieux reste d'avoir tout en mémoire dans un seul document.

C'est une approche très bien adaptée pour un serveur en mode client-serveur.

Dans mon projet OpenSource, j'ai ainsi aussi défini des commandes pour charger des fichiers dans une arborescence de travail sur laquelle plusieurs transformations successives, entre autres, peuvent être appliquées afin de produire les données souhaitées.

XML est vraiment génial mais l'intendance autour est encore quasi inexistante ! Mon projet est tout de même l'occasion de s'apercevoir que ce qui manque n'est pas si compliqué et volumineux que ça : un peu de sens pratique autour d'une notion extrêmement puissante !!!

[kurkaine]

Je suis curieux... Ce n'est pas bien... Est-il possible d'en savoir plus sur ton projet OpenSource, si tu as un site peut-être.

Sinon, merci pour ta réponse.

Je crois que je ne vais pas choisir le XML finalement, ces histoires de sauvegardes m'inquiètes.

A bientôt.

[alain.couthures]

Il te suffit d'aller voir le lien dans ma signature.

Je pense vraiment qu'on peut écrire une petite appli sans avoir grand chose de plus mais, avec le standard, il faut pouvoir faire des sauvegardes à chaque modif ce qui impose de petits volumes et je pense que 2 Mo de données c'est limite !