Je travaille actuellement sur un CMS basé sur XML qui économise des données dans des morceaux appelés "articles". Ceux-ci peuvent être utilisés sur le site Web pour afficher le contenu.
Maintenant, pour le moment, j'ai un fichier XML distinct pour chaque article. Étant donné que la plupart des pages de ce site Web utilisent environ trois à quatre de ces articles, un site Web plutôt petit avec E.G. 20 pages ont environ 100 articles différents. Et là-bas, le même nombre de fichiers XML dans le dossier My / XML / articles.
Serait-il préférable de stocker toutes ces données dans un seul fichier option.xml ou est mon approche actuelle la meilleure?
Pro monoy Fichier - xml / items.xml
pro plusieurs fichiers multi - xml / éléments / *. XML
6 Réponses :
Si vous n'entrez pas simplement la route de base de données, ce qui, pour moi, vous sent évident, je vous suggérerais plusieurs fichiers. La principale raison est que si vous n'utilisez qu'un seul fichier et que vous mettez la mise à jour, votre application doit analyser l'intégralité du fichier lors de l'affichage d'une page qui est une mauvaise chose (TM).
Exactement. Comment les différentes bases de données XML abordent-elles ce problème? À un moment donné, je voudrais imaginer qu'un SGBD aurait juste plus de sens.
Je pense que votre approche actuelle est le meilleur des deux alternatives. Compte tenu de vos utilisateurs, utilisez une interface que vous créez pour modifier les fichiers qu'ils ne rechercheront pas de fichiers dans un répertoire avec de nombreux fichiers de toute façon.
donné ce qu'il faut pour corrompre un fichier, un avantage de nombreux fichiers, est que vous n'obtiendrez pas un gros coup, mais seulement un coup sur un seul fichier. Le verrouillage est également meilleur - comme un fichier à la fois est verrouillé pour écrire, au lieu du «fichier MASTER XML» complet.
Merci pour votre commentaire sur le verrouillage. Pour le moment, le CMS fonctionne à très petite échelle, mais ajoutant un mécanisme de verrouillage pour empêcher la perte de données est quelque chose à garder à l'esprit!
@ Jørg - En référence au fichier XML unique. La perte de données et le verrouillage sont deux choses différentes. Étant donné que vous avez un grand site avec 1000 de pages. Si quelqu'un édite une seule page - le fichier XML complet pour toutes les pages sera verrouillé jusqu'à ce que l'écriture soit terminée (selon le code et la vitesse, puissent prendre du temps). Vous entrez également dans les trucs amusants de la versioning - que se passe-t-il si deux personnes modifient deux pages en même temps? Un fichier => Les changements d'une personne sont écrasés.
Hehe, je parlais de perte de données au cas où deux utilisateurs ouvrent et enregistrent le même fichier en même temps. Le verrouillage d'un fichier résoudra que cela ne fonctionne que lorsque vous travaillez avec plusieurs fichiers. L'utilisation d'un gros fichier XML rend la même tâche beaucoup plus difficile (comme vous l'avez dit, versez et fusionnez des modifications, etc.)
Votre utilisateur fonctionnera-t-il avec les fichiers XML directement ou est simplement un moyen de stocker les données?
Si ce dernier, il s'agit d'un problème technique et d'un accès disque et d'une vitesse d'analyse sont des problèmes pertinents.
Si le premier, la question la plus importante est ce qui a le plus de sens pour l'utilisateur. Vous pouvez ensuite contourner les problèmes techniques avec la mise en cache et tel. Ainsi, en supposant que l'utilisateur fonctionne directement avec les fichiers XML, vous devez vous demander si cela aide ou gêner votre utilisateur à avoir plusieurs fichiers ou un fichier unique. Si chaque élément décrit un composant individuel, il y a peu ou pas de relations avec d'autres éléments, je les mettrais dans des fichiers distincts. Si vous créez un fichier unique avec de nombreux éléments non liés, l'utilisateur passera beaucoup de temps à la recherche de l'élément pertinent. Si vous avez plusieurs fichiers, il peut utiliser le nom du fichier pour sélectionner immédiatement la bonne.
L'utilisateur ne sait pas que c'est des données XML qu'il travaille. C'est juste un moyen de stocker les données. C'est ainsi que la vitesse de l'accès au disque et la vitesse d'analyse est mentionnée dans mes avantages et contre.
Je pense que cela dépend de la quantité de mémoire de votre serveur; quelle est la taille des fichiers XML; et quel analyseur vous utilisez. Si le serveur a beaucoup de mémoire, je pense qu'un fichier XML serait préférable car il pourrait être mis en cache en mémoire, puis facilement analysé. Je pense que cela dépasserait la surcharge io de l'ouverture / la lecture de nombreux fichiers.
En outre, il serait beaucoup plus maintenu et flexible pour l'avenir. Par exemple, si vous souhaitez générer une liste de tous les éléments ou peut-être les rechercher, ce serait alors très difficile en utilisant les fichiers XML distincts. Pour utiliser une analogie de base de données - si vous avez eu des données de page communes dans une DB, créeriez-vous une table séparée pour chaque page? Bien sûr pas.
En fait, votre commentaire sur la recherche - que je n'ai pas vraiment pensé à ce sujet, pour une raison quelconque - a vraiment changé ma position actuelle. Je vais examiner la recherche de mes données et quel avantage un seul fichier peut avoir ici.
Beaucoup de réponses réfléchies ici déjà.
1 gros fichier, ou de nombreux petits fichiers, devrait fonctionner très bien. Les domaines de préoccupation à penser sont plus probables autour de l'administration et de la maintenance. Si c'est difficile à maintenir des éléments parce qu'ils sont dans un tas de fichiers différents, un grand fichier est peut-être la réponse.
Certaines pensées:
Un gros fichier signifie qu'une seule erreur (XML non valide) pourrait supporter toute l'application, tandis que de nombreux fichiers n'auraient aucune incidence sur les pages à l'aide de cet article (s). Atténué par ne pas modifier les données de la production.
Chaque serveur a-t-il sa propre structure de fichiers d'articles? Ou sont-ils situés dans une seule part hautement disponible? Plus il y a de copies des données que vous avez posées, plus vous aurez probablement des données, sortez de la synchronisation sur un serveur particulier qui pourrait être difficile à suivre.
Si vous choisissez 1 fichier, ou de nombreux fichiers, vous pouvez résoudre / résumer tout accès de données (verrouillage, recherche, etc.) dans le code. Le plus de code que vous devez écrire pour faire des choses comme le verrouillage, la recherche, plus vous risquez de boire à avoir à déboguer.
considère les articles de mise en cache pendant une période de temps pour éviter l'accès du disque si la performance commence à devenir un problème.
Vous voudrez peut-être consulter la Moteur de blogs de Dasblog . Je crois que c'est essentiellement un système de gestion de contenu basé sur un fichier XML / texte qui a pris les nombreuses approches de fichiers et qu'il pourrait être utile de revoir.
Si vous stockez tous les documents XML dans un fichier et un fichier d'index qui mappe le nom de chaque document à l'endroit où il commence dans le fichier (Documents), vous obtenez:
Honnêtement, je ne pense pas que cette méthode améliorerait l'heure de chargement d'une page suffisante pour valoir l'effort. Vous avez dit qu'il peut y avoir 100 articles, si vous n'avez pas besoin de la plupart d'entre eux tout en préparant des pages, les stockez tous dans un document augmenteraient l'heure de chargement d'une page (au minimum, au minimum, heure d'accès à un document) . J'irais pour stocker chaque article dans un document, chaque document dans un fichier, tous les fichiers d'un répertoire. Imaginez que (de la même manière à la méthode que j'ai suggérée), le répertoire est un indice qui mappe le nom de chaque document (nom de fichier) à l'endroit où il commence sur le disque (chemin de fichier).