Discussion :

[psylox]

Bonjour/Bonsoir

Je dois créer une interface web correspondant à la hiérarchie du personnel de l'entreprise. Il y aura une section d'administration utiliseé par seulement une personne, qui ne connait rien en programmation et a peu de connaissance en informatique. Une des contraintes majeurs est la rapidité car l'ordinateur de cette personne est peu puissant.

choix 1 :
Une base MySql pour stocker les informations du personnel.
Ces données extraites par php donneront lieu a une représentation de l'arborescence en SVG.
Une version imprimable au format PDF doit aussi etre prévu (via la lib fpdf).

choix 2 :
Stockage des informations utilisateurs dans des fichiers XML.
Transformation du XML en SVG via XSLT.
Transformation du XML sn SVG via XSL-FO.
(transformation coté client ou server? j'ai lu que les 2 étaient possible)

Avec la section d'administration je serai plus tenter de partir sur une base de données mysql qui pour moi est moins lourde d'accès.

Qu'en pensez-vous?Que choisiriez-vous? peut-etre une autre solution?Selon vous lequel de ces choix est le plus rapide, le moins lourd pour le serveur?

Merci

[alain.couthures]

Quels sont les volumes ??? Si ça va tenir dans un PDF, il ne doit pas y avoir beaucoup de personnes !?! Dans ce cas, le XML sera bien suffisant, même pour les mises à jour.

Je ne suis pas sûr que le SVG soit correctement interprêté s'il est généré par une transformation côté client...

J'ai déjà vu une classe PHP permettant de passer d'un SVG à un PDF via FPDF.

Par rapport à l'utilisation d'une base de données, il est facile de localiser un élément dans un document XML dès lors qu'un id y est systématiquement associé et l'API DOM (PHP5) est, certes, un peu verbeuse mais tout de même simple d'utilisation.

[psylox]

Pour le volume de données, il y a un peu moins de 1000personnes.

Pour la transformation SVG, j'ai trouvé les bonnes fonctions Php à utiliser (si quelqu'un en a besoin je donnerai le lien).

Pour ce qui est de passé du SVG en PDF, je ne sais pas si j'en ai vraiment l'utilité. Si j'utilise MySql autant ne pas passer par le SVG avec fpdf, et si c'est du XML pareil avec XSL-FO, il n'est pas nécessaire de passer par du SVG avant, mais je note ça pourra toujours me servir ailleurs

L'utilisation de DOM m'ai familière c'est d'ailleurs cela que je comptais utiliser.

Si vous me dites que le volume de données à brasser n'est pas trop important pour l'utilisation du XML alors je pense que c'est ce que je vais utiliser.

[alain.couthures]

1000 personnes, c'est déjà assez conséquent mais faut-il vraiment toutes les charger systématiquement en mémoire ? Je pense que des tests s'imposent pour voir le comportement serveur (temps de chargement, mémoire occupée,...). Dans une architecture trois tiers, c'est le SGBD qui a la charge de la disponibilité des données mais, avec seulement des fichiers XML, c'est au frontal Web à faire tout le boulot à chaque page (il existe des bases XML pour retrouver l'architecture trois tiers).

Entre SVG et XSL-FO, l'approche n'est pas la même : SVG sera plus adapté pour une page avec une représentation graphique riche alors que XSL-FO sera plus adapté pour un document de plusieurs pages (type traitement de texte) avec entête/bas de page, ...

[GrandFather]

Bonjour,

Dans ce contexte "faible volume/plus de consultations que de mises à jour", la solution XML est viable, d'autant que XML est bien plus adapté qu'un SGBDR pour stocker des données hiérarchiques, du type de celles d'un organigramme. Pour l'interface d'administration, la solution SVG n'est peut-être par contre pas la plus pratique ni la plus performante ; un simple TreeView (à base de HTML et d'une pincée de Javascript) peut suffire.

Pour la partie consultation, envisage, si possible, la mise en cache des documents SVG générés.

[psylox]

Entre SVG et XSL-FO, l'approche n'est pas la même : SVG sera plus adapté pour une page avec une représentation graphique riche alors que XSL-FO sera plus adapté pour un document de plusieurs pages (type traitement de texte) avec entête/bas de page, ...

Oui c'est pour cela que je pensais utiliser XSL-FO pour générer un document pdf, et une image SVG pour la représentation de l'arborescence dans le navigateur web.

1000 personnes, c'est déjà assez conséquent

Dans ce contexte "faible volume/plus de consultations que de mises à jour"

euh? alors pour vous c gros ou faible comme volume de données?

Pour la partie consultation, envisage, si possible, la mise en cache des documents SVG générés.

C'est ce que je pensais faire.

Je vais faire quelques tests, taille de la taille mémoire alloué au script avec l'ouverture d'un fichier xml et récupération de données dans la base de données, ainsi que le temps que cela a mis.

Merci

[GrandFather]

euh? alors pour vous c gros ou faible comme volume de données?

En soi, ce n'est pas tant la taille de la source qui importe que la méthode de parsing qui va être utilisée. Une source de 10 Mo chargée dans un arbre DOM peut gravement plomber les performances d'un serveur, surtout s'il est très sollicité. Parsé avec SAX, cela devient déjà plus raisonnable, l'occupation mémoire étant minimale.

Tel que je comprends ton projet, le parsing de la source XML devrait être faite avec SAX et la construction du document SVG, dont les données sont un petit sous-ensemble de celles de la source, devrait être fait avec DOM. XSLT n'est peut-être pas la solution optimale pour cela, du moins côté serveur.

[psylox]

Donc après des petits tests de rapidité de d'occupation mémoire des scripts (l'un mysql et l'autre xml), j'ai donc opté pour du xml. La taille du fichier xml n'excédaient pas 2mo.

le parsing de la source XML devrait être faite avec SAX et la construction du document SVG, dont les données sont un petit sous-ensemble de celles de la source, devrait être fait avec DOM.

Si j'ai bien compris ce qu'était SAX, le parseur lit le fichier mais ne le charge pas en mémoire, j'entends par la qu'il n'y a pas la construction de l'arbre DOM. En effet cela me semble bien pour créer la structure SVG au fur et à mesure du parcours du document.
Par contre qu'entends tu pars "sont un petit sous-ensemble de celles de la source, devrait être fait avec DOM.", tu veux dire qu'il faut que je mix SAX et DOM ?(je ne connais pas SAX en php, pour le moment j'utilisais une classe composée d'un DOMDocument)

XSLT n'est peut-être pas la solution optimale pour cela, du moins côté serveur.

Donc il vaut mieux que je construise le SVG via php (SAX,...), pourtant cela me semblait plus lourd, non ?
Du coup, pour ce qui est de construire le document pdf, XSL-FO est-il la meilleur solution, ou SAX+pdf serait mieux ?