Utiliser XML comme stockage de données
Je pensais au format XML et à la citation suivante:
"XML n'est pas une base de données. Il n'a jamais été conçu comme une base de données. Ce ne sera jamais une base de données. Les bases de données relationnelles sont une technologie éprouvée avec plus de 20 ans d'expérience en implémentation. Ce sont des produits solides, stables et utiles. Ils ne s'en vont pas. XML est une technologie très utile pour déplacer des données entre différentes bases de données ou entre des bases de données et d'autres programmes. Cependant, ce n'est pas lui-même une base de données. Ne l'utilisez pas comme un seul. "- XML efficace: 50 façons spécifiques d'améliorer votre XML par Elliotte Rusty Harold (page 230, partie 4, point 41, 2e paragraphe )
Cela semble vraiment souligner que XML ne doit pas être utilisé pour le stockage de données et doit uniquement être utilisé pour l'interopérabilité de programme à programme.
Personnellement, je ne suis pas d'accord et le fichier app.config De .NET qui est utilisé pour stocker les paramètres d'un programme est un exemple de stockage de données dans un fichier XML. Cependant, pour les bases de données plutôt que pour les configurations, etc., XML ne doit pas être utilisé.
Pour développer mon propos, j'utiliserai deux exemples:
A) Données sur les clients avec des champs qui sont tous à un seul niveau, c'est-à-dire qu'il existe un certain nombre de champs concernant tous un client sans enfants
B) Données sur la configuration d'une application où les champs et les propriétés imbriqués ont beaucoup de sens
Ma question est donc la suivante: est-ce toujours une déclaration valide et est-il maintenant acceptable de stocker des données en utilisant XML?
EDIT: J'ai envoyé un e-mail à l'auteur de cette citation pour lui demander son entrée/contexte supplémentaire.
Cette citation ne concerne pas l'utilisation de XML comme format de stockage en général (pour lequel cela convient, selon les exigences), mais pour le stockage de type base de données.
Lorsque les gens parlent de bases de données, ils désignent généralement des systèmes de stockage qui stockent d'énormes quantités de données, souvent de l'ordre du gigaoctet ou du téraoctet. Une base de données est potentiellement beaucoup plus volumineuse que la quantité disponible RAM sur le serveur qui la stocke. Comme personne n'a jamais besoin de toutes les données d'une base de données à la fois, les bases de données doivent être optimisées pour une récupération rapide des données sélectives sous-ensembles de leurs données: c'est à cela que sert l'instruction SELECT, et les bases de données relationnelles ainsi que les solutions NoSQL optimisent leur format de stockage interne pour une récupération rapide de ces sous-ensembles.
XML, cependant, ne correspond pas vraiment à ces exigences. En raison de sa structure de balises imbriquées, il est impossible de déterminer où dans le fichier une certaine valeur est stockée (en termes de décalage d'octet dans un fichier) sans parcourir l'arborescence de document entière, au moins jusqu'à la correspondance. Une base de données relationnelle a des index, et la recherche d'une valeur dans un index, même avec une implémentation de recherche binaire primitive, est une simple recherche O (log n), puis accéder aux valeurs réelles n'est rien d'autre qu'une recherche de fichier (par exemple fseek(data_file_handle, row_index * row_size)), qui est O (1). Dans un fichier XML, le moyen le plus efficace est d'exécuter un analyseur SAX sur votre document, en effectuant énormément de lectures et de recherches avant d'accéder à vos données réelles; vous pouvez difficilement obtenir cela mieux que O (n), à moins que vous n'utilisiez des index, mais alors, vous devrez reconstruire l'intégralité de l'index pour chaque insertion (voir ci-dessous).
L'insertion est encore pire. Les bases de données relationnelles ne garantissent pas l'ordre des lignes, ce qui signifie qu'elles peuvent simplement ajouter de nouvelles lignes ou remplacer toutes les lignes marquées comme "supprimées". C'est extrêmement rapide: la base de données peut simplement conserver un pool d'emplacements accessibles en écriture; obtenir une entrée du pool est O(1) sauf si le pool est vide; pire cas, le pool est vide et une nouvelle page doit être créée, mais c'est aussi O (1) . En revanche, une base de données basée sur XML devrait tout déplacer après le point d'insertion pour faire de la place; c'est O (n). Lorsque les index entrent en jeu, les choses deviennent encore plus intéressantes: les index de base de données relationnelle typiques peuvent être mis à jour avec complexité relativement faible, par exemple O (log n); mais si vous souhaitez indexer vos fichiers XML, chaque insertion modifie potentiellement l'emplacement sur disque de chaque valeur du document, vous devez donc reconstruire l'intégralité de l'index . Cela vaut également pour les mises à jour, car la mise à jour, par exemple, du contenu texte d'un élément, peut changer sa taille, ce qui signifie que le XML consécutif doit changer. Une base de données relationnelle ne devez toucher l'index du tout si vous mettez à jour une colonne non indexée; une base de données XML devrait reconstruire l'intégralité de l'index pour chaque mise à jour qui modifie la taille du nœud XML mis à jour.
Ce sont les inconvénients les plus importants, mais il y en a plus. XML est très verbeux, ce qui est bon pour la communication de serveur à serveur, car il ajoute de la sécurité (le serveur récepteur peut effectuer toutes sortes de vérifications d'intégrité sur le XML, et si quelque chose s'est mal passé dans le transfert, le document est peu susceptible de valider ). Pour le stockage de masse, cependant, cela tue: il n'est pas rare d'avoir 100% ou plus de surcharge pour les données XML (il n'est pas rare de voir des ratios de surcharge dans la plage de 1000% pour des choses comme SOAP = messages), alors que les schémas de stockage de base de données relationnelle typiques n'ont qu'une surcharge constante pour les métadonnées de table, plus un tout petit peu par ligne; la plupart de la surcharge dans les bases de données relationnelles provient de largeurs de colonne fixes. Si vous avez un téraoctet de données, 500% les frais généraux sont tout simplement inacceptables, pour de nombreuses raisons.
XML est moche pour le stockage de données. Tout d'abord, il est très bavard. Les données stockées dans un fichier XML prendront beaucoup plus d'espace disque que les mêmes données stockées dans tout système de base de données raisonnable. Dans un enregistrement XML, le nom d'un champ particulier sera stocké deux fois, ainsi que la représentation sous forme de chaîne des données. Ainsi, par exemple, pour stocker un seul entier dans un champ appelé "foobar", vous vous retrouvez avec cette chaîne de 19 octets:
<foobar>42</foobar>
D'un autre côté, une vraie base de données stockera cela comme une seule valeur entière, en prenant 4 octets. Si votre base de données est petite, cela ne signifie pas grand-chose, mais si vous avez 10 000 enregistrements, c'est un problème.
Deuxièmement, un XML doit être analysé à partir du texte chaque fois que le fichier est lu. Pour le champ ci-dessus, une vraie base de données lit simplement les données binaires en mémoire à partir de l'offset dans lequel elle sait qu'elle a stocké le champ "foobar". Si le fichier est stocké en XML, elle doit lire le champ "foobar", analyser ce texte , déterminez de quel champ il s'agit, puis analysez la chaîne "42" et convertissez-la en binaire 42.
Ainsi, les pénalités de performances pour l'utilisation de XML sont énormes. Les avantages de XML sont qu'il est quelque peu lisible par l'homme et qu'il permet un transfert facile des données entre des systèmes complètement séparés. Aucun de ces avantages ne s'applique à une base de données locale.
La seule exception est les fichiers de configuration, qui sont généralement petits et doivent généralement être modifiables par l'homme.
Une base de données XML sera absolument plus volumineuse et plus lente que tout système SQL raisonnable. À moins que vous ne trouviez un avantage de contrepoids dans la lisibilité humaine ou l'interopérabilité, il est tout simplement inutile de l'utiliser pour le stockage de données.
XML est viable selon le contexte. Si vos données sont assez statiques et ne changent pas beaucoup (exemples de données par exemple), oui XML est une bonne utilisation.
Les paramètres de configuration, les exemples de données (même s'il s'agit de millions de lignes, mais qui changent rarement), sont tous de bonnes utilisations de XML.
La lecture/écriture sur le disque dur coûte cher, bien plus que l'accès aux données à partir d'une pile Oracle/Sql.
Cela semble vraiment souligner que XML ne doit pas être utilisé pour le stockage de données et ne doit être utilisé que pour l'interopérabilité de programme à programme.
Votre prémisse est défectueuse.
Le paragraphe que vous citez dit en fait que XML ne remplace pas une base de données, et non qu'il ne devrait pas être utilisé pour stockage de données.
Il est clair qu'un fichier de paramètres n'est pas la même chose qu'une base de données, et donc différentes technologies peuvent (et devraient?) Être utilisées.
Corrigez-moi si je me trompe, mais vous semblez avoir plus d'expérience avec les langages de balisage qu'avec les bases de données. Si vous avez un peu d'expérience avec les bases de données, vous vous rendrez compte à quels domaines les deux technologies différentes sont adaptées.
C'est vraiment subjectif. Cette citation est, comme, l'opinion de quelqu'un, l'homme.
Honnêtement, je pense que XML est une alternative viable à une base de données car il présente de multiples avantages par rapport à un RDMS, y compris une faible surcharge, ce qui équivaut à un stockage moins cher (en particulier lorsque vous utilisez un service d'hébergement qui facture les bases de données séparément).
Jetez un œil à dasBlog et BlogEngine . Ces deux applications utilisent par défaut xml pour le stockage.
Cela dit. Ce n'est pas un RDMS, et si vous avez une grande volatilité (beaucoup de mises à jour, insertions ou suppressions) dans vos données ou si vous avez besoin d'une haute disponibilité, utilisez une base de données. XML est parfait pour stocker de petites choses comme les données de configuration et les données à faible volatilité.
XML n'a jamais voulu être une base de données ou la remplacer.
XML est principalement défini pour les documents Web qui allows for the creation of customized tags for individual information fields. Cependant, vous n'obtiendrez jamais une gestion centralisée des données relationnelles avec.
ma question est, est-ce toujours une déclaration valide et est-il maintenant acceptable de stocker des données en utilisant XML?
Je vois votre point dans votre exemple sur les fichiers de configuration .NET. Cependant, tout autre format de fichier aurait pu être utilisé. En fait, dans le passé, ces paramètres étaient stockés dans des fichiers texte ordinaires appelés INI.
Je vois que la déclaration que vous avez présentée en gris, est valide et correcte si vous définissez une base de données comme un système logiciel.
La définition de XML dans XML-Definition indique que "(XML) est un langage de balisage qui définit un ensemble de règles pour coder les documents dans un format à la fois lisible par l'homme et lisible par la machine."
Cette définition se concentre sur la lisibilité et le langage plutôt que sur les mécanismes pour gérer les données.
Par rapport à un SGBDR, XML ne permet pas d'insérer et de supprimer des lignes de manière aléatoire dans un fichier XML. Par exemple, si vous avez 1000000 lignes et que vous souhaitez supprimer des lignes au hasard, même dans un environnement XML à utilisateur unique, le fichier ne serait pas un bon choix pour une base de données. De plus, XML ne fournit aucun mécanisme natif de verrouillage des données. En fait, comme XML n'est pas un logiciel, toutes les propriétés ACID (atomicité, cohérence, isolation, durabilité) qui garantissent que les transactions de base de données sont traitées de manière fiable dans un environnement partagé sont laissées au développeur pour la construction (à l'exception de la durabilité). XML n'a pas de spécification robuste pour gérer l'intégrité des données dans les fichiers XML, sans parler des différents serveurs (par exemple, le fichier xml client et le fichier xml de commandes - Aucun FK pour appliquer l'intégrité).
Ce qui précède n'est pas une énumération de ce qui manque à XML, mais pourrait servir de justification rapide de la déclaration selon laquelle XML n'est pas un logiciel de base de données .
Pourquoi voudriez-vous réellement utiliser XML pour stockage de données en premier lieu? Je veux dire, c'est un langue après tout ...
Bien que l'on puisse dire que c'est un format flexible et facile à comprendre, cela ne s'applique que lorsque vous devez effectuer une modification manuelle des fichiers. Lorsque vous interagissez réellement avec la base de données avec une interface commune (récupérer les données X qui répondent aux exigences Y et Z, stocker/mettre à jour les données X, ...) ces avantages deviennent nuls.
Réponse courte: cela dépend.
Réponse longue: De mon point de vue, cela dépend fortement de la quantité de données que vous souhaitez stocker. Par exemple. si vous avez quelques objets dans votre application pendant l'exécution et que vous souhaitez les stocker après avoir exécuté l'outil, un fichier XML convient parfaitement. Cependant, si votre boutique en ligne compte 5000 clients et encore plus de commandes, une base de données serait un stockage de données plus approprié.
De plus, je pense que le stockage des paramètres dans une base de données et non dans un fichier comme app.config n'est dans la plupart des cas pas très utile, mais je ne pense pas que cet exemple prouve que la citation est incorrecte.
XML est un excellent choix pour les paramètres de configuration. Non seulement les fichiers XML sont faciles à analyser/mettre en évidence dans un IDE, mais ils sont très faciles à éditer pour les non-programmeurs. Je les trouve incroyablement utiles dans les scénarios de développement Web où les tâches de maintenance sont effectuées par des concepteurs et des gestionnaires de contenu.
XML ne doit généralement pas être utilisé comme source de données principale pour toute application non triviale. La surcharge de sérialisation/désérialisation demande à elle seule une solution différente.
Je suis d'accord que ce n'est pas une base de données relationnelle. Je pense que l'auteur dit simplement dans la citation de ne pas l'utiliser comme un seul.
Cela dit, même si vous en avez besoin ou non. Si vous n'avez pas vraiment besoin de faire beaucoup de requêtes sur les données, et que vous avez uniquement l'intention de les stocker et de les récupérer plus tard en fonction de certains critères de requête limités, vous avez besoin du stockage et de la récupération de DOCUMENT XML - pas d'une base de données relationnelle.
Il existe de nombreuses applications qui ont simplement besoin de stocker un document contenant des données pour être récupérées ultérieurement. Si tel est le cas, il est inutile de créer un schéma basé sur SQL, d'analyser le XML, puis de le sérialiser dans la base de données uniquement pour faire l'inverse plus tard. Il y a beaucoup de surcharge de code potentiellement impliquée dans cela. Il y a moins si vous le faites correctement.
Vous pouvez utiliser des outils ORM comme Hibernate et des outils comme Apache Axis afin de générer automatiquement pratiquement tout le code dont vous auriez besoin pour créer un service qui gère simplement les opérations CRU simples. Vous devrez bien sûr envelopper cela dans l'authentification, et vous voudrez peut-être séparer les données en fonction de l'utilisateur, du niveau d'accès, etc. Vous pouvez même vouloir limiter les opérations qu'un utilisateur donné est autorisé à effectuer via SOAP service par exemple.
En ce sens, vous faites plus de gestion de contenu qu'autre chose.
Le terme base de données peut faire référence aux données brutes uniquement ou au système de gestion de base de données. Cette définition fait une grande différence dans tout l'argument.
Si nous utilisons la définition RDBMS, alors XML a très peu dans ce sens. Vous obtenez très peu en termes de garanties ACID (vous devez écrire votre propre code pour les accomplir). Si vous en avez besoin (et la plupart des systèmes transactionnels en ont besoin), vous êtes déjà en grande difficulté. Je pourrais donner une liste de centaines de fonctionnalités qui sont considérées comme acquises avec les SGBDR, que vous devrez réinventer et réimplémenter. Pensez aux modèles de sécurité, à la réplication, aux sauvegardes, pour n'en nommer que quelques-uns.
Dans le sens ci-dessus, non, XML n'est pas une base de données et vous ne devriez pas essayer de l'utiliser comme une seule.
Si nous utilisons la définition de "données brutes", XML s'en sort beaucoup mieux, mais toujours pas si bien. Comme d'autres l'ont souligné cependant, il est extrêmement verbeux en général, généralement dépourvu d'encodage binaire et comportant des balises en double, etc. Ce sont des compromis faits pour que XML puisse être lisible par l'homme - fondamentalement, l'efficacité est l'ennemi de cette exigence . XML n'est pas non plus particulièrement adapté aux situations les plus simples où vous insérez des enregistrements en continu. En supposant que vous voulez que votre fichier XML soit valide, vous avez besoin d'une seule balise de fermeture, ce qui signifie que l'ajout d'un enregistrement signifie que vous devez remonter les balises à la fin. C'est assez cher (comment savoir où commence cette balise? Et s'il y a plusieurs "tables", faut-il simplement remonter le fichier entier?), Et si vous voulez contourner ce problème, vous réinventerez une approche similaire à de nombreuses bases de données - répartissant les tableaux sur plusieurs fichiers et augmentant dynamiquement ces fichiers selon les besoins.
Il y a des situations où XML est approprié - les fichiers de configuration sont un excellent exemple, car ils sont généralement petits et la lisibilité humaine est une excellente fonctionnalité. Avoir une base de données juste pour un fichier de configuration peut être exagéré.
Les bases de données, en revanche, sont excellentes lorsque vous avez des milliers (ou des millions/milliards) d'enregistrements et que de nombreux utilisateurs les mettent à jour simultanément. Alors oui, XML n'est pas une base de données, et vous ne devez pas l'utiliser comme tel. Votre exemple se trouve être l'une de ces situations où vous n'avez pas eu besoin d'une base de données en premier lieu, et XML est le meilleur ajustement.
La façon dont je le vois est la suivante: si vous utilisez XML comme base de données (par exemple, comme magasin de sauvegarde pour un système transactionnel), vous finirez par réinventer et réécrire un SGBDR. C'est une très mauvaise façon de dépenser votre temps et votre énergie. Je pense que c'est aussi ce que disait cette citation.