Bonjour,

Développant une application de gestion de cv, je me pause des questions au sujet de l'intérêt d'une BDD.

Actuellement, mes données sont regroupées dans un fichier XML. Via PHP, j'applique une feuille de style XSLT à ce XML pour générer mon code XHTML auquel j'applique une feuille de style CSS et un script JS.

Plutôt partisan de séparer les couches, j'ai naturellement pensé à séparer mes données du XML pour les intégrer dans MySQL.
Ceci dit, à l'inverse des autres types de séparation (structure/présentation/comportement/traitement), je n'arrive pas à y déceler les mêmes avantages.

Par exemple, si je prends un formulaire et que je reçois des données d'un utilisateur, je me voyais bien effectuer le traitement de l'envoi puis mettre à jour mon XML via DOM. De là, mon XSLT, dans lequel se trouveraient certaines conditions, boucles, choix, etc..., mettrait automatiquement à jour le code XHTML (voire CSS et JS) et puis... c'est tout.

Pour m'assurer que les données reçues du visiteur soient correctes, j'imposerais par exemple que celles-ci respectent les règles établies par une DTD, un XML Schema ou un RelaxNG afin de les valider.

Si j'ai besoin de faire une recherche sur les données enregistrées, je peux entre autres me servir de DOM.

Donc, si j'intégrais mes données dans une BDD, qu'est-ce que cela pourrait m'apporter ?

Je n'y vois que des traitements supplémentaires... et pas l'avantage.

D'habitude, la séparation de deux couches les rend indépendantes et plus portables mais, dans le cas de la séparation des données et du XML :

- XML est déjà portable.
- En vue d'améliorer la sémantique, j'ai l'habitude de nommer mes balises XML de manière descriptive, ce qui fait que l'indépendance des données par rapport à la structure ne me semble pas judicieuse.

... sans compter que si j'intégrais les données dans MySQL, je devrais :

1- traiter les données
2- les intégrer dans la BDD
3- les extraire
4- établir mon XML

... les points 2 et 3 venant donc s'ajouter par rapport à ma méthode initiale.

On a pourtant l'habitude de dire que XML n'est pas une base de données et qu'il existe d'ailleurs des BDD XML (sur lesquelles on peut se servir de XQuery avec Xpath) à l'instar des BDD relationnelles... Bref, je dois être un peu cruche mais je ne vois pas ce qu'une BDD peut m'apporter...

Qu'en pensez-vous ? Aurais-je omis quelquechose ? Et dans quel cas la BDD vous semble indispensable ?

Bonjour,

voici comment je vois les choses de mon côté.

Pour moi, un fichier XML ou une DB sert à stocker des données.
Pour le XML c'est une exception (pour moi).

Mais il faut faire des choix, le XML est un meta-langage de structuration de données, il peut donc dans sa définition servir à stocker des données.
Et une DB ne sert qu'à ça.

Maintenant, si l'on compare les performances pour le besoin, on peut arriver à ça :

• pour de petites données (chemin relative, adresse email du webmaster etc.) le XML est recommandé car son accès est plus rapide qu'à une DB ;
  pour des données plus grosses, le système gère mieux les gros flux de données dans le cas d'une DB (ça sert à ça à l'origine) ;

Donc voilà mon utilisation des deux : XML pour des petites données, et DB pour les grosses, à cause des ressources que ça prend.
C'est vrai que ça sert à rien de se connecter à la base pour récupérer l'adresse email du webmaster. Un canon pour tuer une mouche. Ca me paraît un peu logique.
Mais il faut voir les types de données encore une fois. Pour les traductions je me sers de fichier XML aussi. Ils sont un peu gros par moment, mais très facile à manipuler.

Il faut voir en fonction du type de données, de leur importance, et de leur taille pour justifier le choix entre XML et une DB

Les bases de données (même les bases de données «fichier» comme SQLite) supportent beaucoup mieux la montée en charge qu'un fichier XML, dont l'utilisation entraînera une chute dramatique des performances lors d'une grosse montée en charge.
De même une base de donnée permet de faire des requêtes croisées entre plusieurs tables, ce qui est plus délicat avec XQuery je crois (mais là je m'avance un peu vu que je ne connais pas le langage XQuery).

Si je considère la finalité des données; une base de données reste un contenue de fichier sur un disque dure...

Tu peux même enregistré tes donnés en .txt dans un dossier et dire que tu as une base de données après tout...

L'intérêt de la base de donnée au sens ou on l'entend en PHP est d'avoir un moteur de traitement qui va optimisé
- le stockage (encodage/compression...)
- les requêtes

Si au final tu n'as que des profil d'user avec quelque données alors là oui la base de donnée n'à aucun intérêt signifiable. Mais si tu dois effectuer des requêtes complexe affin de bien traité tes donnés là par contre tu aura besoin d'une base de donnée ne serait-ce que pour te simplifier la vie.

Essay de faire des jointures à partir de donnés issue de xml... certe on peut.. mais je te souhaite bien du plaisir (pauvre server )

=> tout dépend de la nature de tes données et de leur utilisation

Bonsoir,

L'intérêt de la base de donnée au sens ou on l'entend en PHP

Une base de données est totalement indépendante du langage utilisé pour manipuler les données quelle contient ou sa structure, seules les instructions différent en fonction du langage.

Hello,

Merci pour vos remarques.

Il est vrai que je n'avais pas vraiment pensé à la charge que cela pouvait représenter donc je vais revoir ma copie. ^^

Cela dit, lorsqu'on fonctionne en XML, il me semble qu'il y ait tout intérêt à se servir de bases de données XML et non relationnelles car XQuery n'est pas aussi boiteux qu'on voudrait bien le croire. Concernant les requêtes croisées, c'est justement l'une de ses forces... Il permet par exemple de faire des appels à de multiples sources (fichier XML, base de données relationnelles, données objet) tout en générant un résultat XML... le tout dans une même requête. De même, il peut générer plusieurs représentations différentes à partir d'une même source.
Il me semble que ses limitations sont plus dûes au fait que des fonctions telles que la suppression sont inexistantes (mais contournables). A l'inverse, on peut créer ses propres fonctions.

Je pense que ces documents sont tout de même assez parlant :
http://developpeur.journaldunet.com/tut ... uery.shtml
http://www.w3.org/TR/xquery-use-cases/#seq-data
http://www.w3schools.com/xquery/default.asp

Tu ne vois pas l'interêt des autres BDD car tu utilises déjà un système de BDD en utilisant XML. Seulement les vraies BDD sont gérées par un SGBD qui permet de faire ce que la technologie XML ne peut le remplacer.

XML est une nouvelle technologie basée principalement sur le transport de données et leur gestion et sécurité.

L'avantage d'un SGBD est qu'il emploi SQL pour décrire et manipuler les données dans le cadre d'une BDD intrinscèque tout en permettant le partage et la sécurité des données et en gérant les accès utilisateurs.

XML, XSL, CSS et HTML sont des techniques de présentation WEB de données elle ne remplacent en aucun cas un SGBD.

La plupart des SGBD échange les données sous format XML pour notamment titer profit des technologies XHTML (Web)

Un exemple de la limite XML par rapport à SQL/SGBD, est certainement le partage des données en mode multi-utilisateurs et la gestion des transactions.

Comment par ta solution XML standalone, comptes-tu résoudre les conflits des actions Ajouts, modifications et suppressions sur une même source de données en mode multi-utilisateurs?

Comment XML permettra-t-il de placer des contraintes d'intégrité relationnelles, des procédures automatiques correctives de l'intégrité comme les triggers de cascade.

Comment XML permettra-il de stocker des procédures métiers avec les données.

Ne vois-tu pas que pour manipuler un document XML, il faudrait utiliser un analyseur DOM et dans la plupart des cas un langage de programmation pour écrire les procédures d'ajout, modification et suppression de données dans l'arborescence XML?

Si XML vu comme ça remplacerait un SGBDR, quel retour vers le passé alors!z

Autre point important et purement technique. Il y a deux débat en un : le langage de requêtage (XQuery vs SQL) et le système de stockage des données (BDD vs "fichier-qu'on-gère-soit-même", le point qui m'intéresse). Si ta solution XML est basée sur un fichier que tu crées et mets à jour toi-même, tu cours un plus grand risque de corrompre tes données. (race condition, écriture incomplète, etc...) Même en vérouillant ses fichier avec flock() on peut avoir des surprises et on se retrouve à investir un temps fou à essayer de s'en protéger.

Ceci dit, je crois qu'il existe de systèmes de bases de données qui permettent de requêter en XQuery si tu y tiens absolument. (je me rappelle surtout que les performances étaient désastreuses et que les développeurs s'arrachaient les cheveux pour l'optimiser, j'espère que la situation s'est améliorée depuis )

Salut,

Merci sadeq et Hubert.

En fonction de vos remarques, je tente d'élaborer la chose un peu différemment.

En gros, j'ai un formulaire pour établir un cv. Chaque donnée de ce formulaire (titres, labels, légendes) se trouvent dans un fichier XML. Pour certains groupes, je dois donner la possibilité de les multiplier.
Par exemple, si on prend le groupe suivant : ... je peux avoir une ou plusieurs expériences. Tout le monde n'a pas 10 expériences différentes donc il n'y a pas d'intérêt particulier à fournir d'entrée de jeu 10 champs "date", 10 champs "société" et 10 champs "descriptif" non compressibles/extensibles.

En même temps, la multiplication des champs ne doit toucher que l'utilisateur qui le demande... et non les autres. Du coup, je ne peux pas écrire dans ce fichier XML pour modifier le nombre de champs car l'utilisateur A se retrouverait avec le nombre de champs de l'utilisateur B à son premier échange avec le serveur.

Aussi, la solution la plus réactive et prenant le moins de ressources est de le faire via JS/DOM/Ajax mais, c'est dès lors considérer cette multiplication comme optionnelle puisque tout le monde n'a pas JS. Si je procède ainsi, on sait qu'environ 10% des utilisateurs n'y ont pas accès et se retrouveront alors avec un seul groupe. mmh... ça se complique donc...

Il me faut quelquechose qui se fasse côté serveur mais qui en même temps ne soit disponible que pour l'utilisateur courant.

La solution : PHP/DOM

Je multiplie mes éléments à la volée sans les sauvegarder dans le fichier XML et j'obtiens bien le résultat escompté. N'importe quel utilisateur peut définir ses propres expériences sans que ça touche les autres.
Une fois tous les champs renseignés et vérifiés, j'insère les données fournies par l'utilisateur (en fonction de l'arbre DOM en mémoire) au sein de la BDD. Pour améliorer la vitesse de l'application tout en soulageant le serveur, j'ajoute alors la couche JS/DOM/Ajax pour traiter la multiplication des champs.

En somme, je n'utilise la BDD que pour les données utilisateurs et non pour les différents champs, ce qui améliore la vitesse d'affichage vu qu'il n'y a qu'à parser mes documents (absence de requête SQL (ou autre )). De même, via la couche JS/DOM/Ajax, je minimise les interactions avec le serveur pour 90% des utilisateurs.

Qu'en pensez-vous ? Cela vous semble-t-il tenir la route


Pour en revenir à cette discussion (BDD XML vs BDD relationnelle... ce qui induit plus ou moins XQuery vs SQL), j'ai cru comprendre qu'elles existent ces BDD XML gérant les conflits en mode multi-utilisateurs, la sécurité, l'intéropérabilité, etc... C'est le cas de SQL Server 2005 il me semble mais il y en a d'autres (ouf ! ). L'avantage de ce type de BDD est qu'elles implémentent des technologies telles que XQuery et XPath (voire XLink peut-être ?). Celles-ci sont formées différemment des BDD relationnelles en reprennant le concept de l'arbre XML.

Il n'y a pas si longtemps, XQuery 1.0 et XPath 2.0 sont passées au stade de recommendations, ce qui leur confère quand même une certaine maturité/fiabilité. Reste à voir comment c'est implémenté, ce que je ne sais pas pour ma part. ( c'est sans doute ce point que tu as voulu souligner, Hubert )

Maintenant, pour le peu que j'en ai compris, XQuery et XPath permettent d'accéder plus rapidement aux données (sauvegardées sous leur forme XML) que ne le ferait SQL et les possibilités sont plus étendues.
Je fais comme tout le monde dans ce sujet, je m'avance peut-être un peu aussi mais je dis ça par rapport aux liens que je vous ai montré dans mon intervention précédente.
XLink, quant à lui, permet de lier directement les données contenues dans la base au document affiché, ce qui supprime les requêtes... Ca, c'est ce qu'on m'en a dit, je n'ai pas vérifié. C'est ce qui fait que j'ai tendance à croire que ces BDD XML sont des solutions plus puissantes que les BDD relationnelles. Le seul bémol que j'y trouve, c'est la complexité induite et la remise en cause de nos habitudes.
Pour finir, il me semble que la frontière entre ces deux types de BDD se réduise étant donné que certaines BDD relationnelles implémentent XQuery.

Je multiplie mes éléments à la volée sans les sauvegarder dans le fichier XML et j'obtiens bien le résultat escompté.

erf... Ce n'est pas possible. Faut de toute façon sauvegarder dans un fichier pour que ce soit pris en compte...
... temporaire en fonction de la session utilisateur peut-être...
... auquel cas faut que je le supprime ensuite si je ne veux pas faire exploser le serveur...

<mode_success>va peut-être avoir déjà mal là si j'ai 2000 utilisateurs qui font ça en même temps </mode_success>

<mode_reflexion> la base de données est peut-être plus adaptée pour cette tache en effet </mode_reflexion>

Bonjour,

Ma position est surement trop simpliste mais celle que j'applique.

XML ==> Transfert de données entre systèmes hétérogènes.
SGBD(R) ==> Manipulation de données.

En règle générale j'arrive à m'en sortir sans trop de casse.

EDIT : j'efface mon post et recrée un topic dans la rubrique XML, cela me parrait plus approprié