Xml ou Sqlite, Quand abandonner Xml pour une base de données ?

Question

J'aime beaucoup Xml pour sauvegarder des données, mais quand est-ce que sqlite/base de données devient la meilleure option ? par exemple, quand le xml a plus de x ou est supérieure à y MB ?

Je suis en train de coder un lecteur rss et je crois que j'ai fait le mauvais choix en utilisant xml plutôt qu'une base de données sqlite pour stocker un cache de todos les éléments de l'alimentation. Il y a des flux qui ont un fichier xml de ~1mb après un mois, un autre a plus de 700 éléments, tandis que la plupart n'ont que ~30 éléments et ont une taille de ~50kb après un mois. plusieurs mois.

Pour l'instant, je n'ai pas l'intention de mettre en place un plafond, car j'aime pouvoir effectuer des recherches dans tous les domaines.

Donc, mes questions sont :

1. Quand la surcharge de sqlite/bases de données est-elle justifiée par rapport à l'utilisation de xml ?
2. Est-ce que les quelques gros fichiers xml justification suffisante pour la base de données lorsqu'il y a beaucoup de petits même les plus petites grandiront avec le temps ? (une longue long temps)

actualisé (plus d'infos)

Chaque fois qu'un flux est sélectionné dans l'interface graphique, je recharge tous les éléments du fichier xml de ce flux.

Je dois également modifier l'état de lecture/non-lu, ce qui semble très compliqué lorsque je parcours en boucle tous les nœuds du fichier xml pour trouver l'élément et le mettre en lecture/non-lu.

Answer 1

Le XML est idéal pour stocker des données qui ne sont pas complètement structurées et que vous souhaitez généralement échanger avec une autre application. Je préfère utiliser une base de données SQL pour les données. Le XML est sujet à des erreurs car vous pouvez provoquer des erreurs subtiles dues à des fautes de frappe ou des omissions dans les données elles-mêmes. Certains cadres d'application open source utilisent trop de fichiers xml pour la configuration, les données, etc. Je préfère les avoir en SQL.

Puisque vous demandez une règle empirique, je dirais qu'il faut utiliser des données d'application, une configuration, etc. basées sur XML si vous comptez les configurer une fois et ne pas y accéder ou les rechercher souvent. Pour les recherches actives et les mises à jour, il est préférable d'utiliser SQL.

Par exemple, un serveur web stocke les données d'une application dans un fichier XML et vous n'avez pas vraiment besoin d'effectuer des recherches complexes, de mettre à jour le fichier. Le serveur web démarre, lit le fichier XML et c'est tout. XML est donc parfait ici. Supposons que vous utilisiez un framework comme Struts. Vous devez utiliser XML et les configurations d'action ne changent pas beaucoup une fois que l'application est développée et déployée. Donc, encore une fois, le fichier XML est un bon moyen. Maintenant, si votre application développée avec Struts permet des recherches étendues, des mises à jour et des suppressions, alors SQL est le moyen optimal.

Bien sûr, vous rencontrerez certainement un ou deux développeurs dans votre organisation qui ne chanteront que XML ou SQL et proclameront que XML ou SQL est la seule voie à suivre. Méfiez-vous de ces personnes et faites ce qui vous semble bon pour votre application. Ne vous contentez pas de suivre une "religion technologique".

Pensez à des choses comme la fréquence à laquelle vous devez mettre à jour les données, la fréquence à laquelle vous devez effectuer des recherches dans les données. Vous saurez alors ce qu'il faut utiliser : XML ou SQL.

Answer 2

Je suis d'accord avec @Bradley.

Le XML est très lent et n'est pas particulièrement utile en tant que format de stockage. Pourquoi s'en préoccuper ? Allez-vous modifier les données à la main à l'aide d'un éditeur de texte ? Si oui, XML toujours n'est pas un format très pratique comparé à quelque chose comme YAML. Avec quelque chose comme SQlite, les requêtes sont plus faciles à écrire, et il y a une API bien définie pour entrer et sortir vos données.

Le XML convient parfaitement si vous devez envoyer des données d'un programme à l'autre. Mais au nom de l'efficacité, vous devriez probablement produire le XML au moment de l'envoi et l'analyser en "données réelles" au moment de la réception.

Tout ce qui précède signifie que votre question sur "quand les frais généraux d'une base de données sont justifiés" est en quelque sorte sans objet. XML a des frais généraux bien plus élevés, tout le temps, que SQlite. (Les bases de données complètes comme MSSQL sont plus lourdes, notamment en termes de frais généraux d'administration, mais c'est une question totalement différente).

Answer 3

Le XML peut être stocké en tant que texte et en tant que format de fichier binaire.

Si votre objectif principal est de permettre à un ordinateur de lire/écrire un format de fichier de manière efficace, vous devez travailler avec un format de fichier binaire.

Les bases de données sont un moyen facile à utiliser pour stocker et conserver des données. Elles ne sont pas le moyen le plus rapide de stocker des données sous forme de fichiers binaires.

Ce qui peut accélérer les choses, c'est l'utilisation d'une base de données en mémoire / d'un type de base de données. Sqlite a cette option.

Et cela semble être la meilleure façon de le faire pour vous.

Answer 4

À mon avis, vous devriez utiliser SQLite (ou une autre base de données intégrée appropriée) chaque fois que vous n'avez pas besoin d'un format de fichier en texte pur. Notez que c'est une exception assez importante. Il existe de nombreux scénarios qui requièrent des formats de fichiers en texte pur, ou qui en tirent profit.

En ce qui concerne la surcharge, SQLite se compile à quelque chose comme 250 k avec des drapeaux normaux. De nombreuses bibliothèques d'analyse XML sont plus volumineuses que SQLite. Vous n'obtenez aucun gain de concurrence en utilisant XML. Le format de fichier binaire de SQLite va supporter des écritures beaucoup plus efficaces (en grande partie parce que vous ne pouvez pas ajouter à la fin d'un fichier XML bien formaté). Et même la lecture des données, dont la plupart sont, je suppose, des accès aléatoires, sera plus rapide avec SQLite.

Et pour couronner le tout, vous avez accès aux avantages de SQL comme les transactions et les index.

Edit : J'ai oublié de mentionner. Un avantage de SQLite (par rapport à de nombreuses bases de données) est qu'il permet d'utiliser n'importe quel type dans n'importe quelle ligne et n'importe quelle colonne. En gros, avec SQLite, vous avez la même liberté que vous avez avec XML en termes de types de données. Cela signifie également que vous n'avez pas à vous soucier d'imposer des limites aux colonnes de texte.

Answer 5

Il convient de noter que de nombreuses grandes bases de données relationnelles (Oracle et SQLServer) disposent de types de données XML pour stocker des données dans une base de données et utilisent XPath dans l'instruction SQL pour accéder à ces données.

Il existe également des bases de données XML natives qui fonctionnent de manière très similaire à SQLite, en ce sens qu'il s'agit d'un fichier binaire contenant une collection de documents (qui pourrait être une table). Vous pouvez ensuite effectuer des XPath/XQuery sur un seul document ou sur la collection entière. Ainsi, avec une base de données XML, vous pouvez faire des choses comme stocker les données du jour en tant que document XML distinct dans la collection... de sorte que vous n'avez qu'à utiliser ce seul document lorsque vous traitez les données du jour. Mais écrire un XQuery pour trouver les données historiques sur la collection de documents pour cette personne. Génial.

J'ai utilisé Berkeley XMLDB (maintenant soutenu par Oracle). Il en existe d'autres si vous cherchez "Native XML Database" sur Google. Je n'ai pas constaté de problème de performance dans le stockage/la récupération de données de cette manière.

XQuery est une bête différente (mais qui vaut la peine d'être apprise), mais vous pourrez peut-être utiliser les XPaths que vous utilisez actuellement avec de légères modifications.