pour un 1) Fichiers XML unique pour chaque type de fonctionnalités, sur le répertoire de l'utilisateur: basicinfo.xml, commentaires.xml, photos.xml, ...
2) mySQL, même si vous ne savez pas comment organiser à ce sujet. Peut-être des tables séparées pour chaque fonctionnalité? Par exemple. Des tables pour commentaires, où les colonnes sont ID, à partir de messages, le temps ?
Je sais que XML n'est pas conçu pour le stockage et PHP (c'est la langue que j'utilise) doit lire l'ensemble du fichier XML et stocker en mémoire avant qu'il ne soit utilisé.
Mais, voici les raisons pour lesquelles je préfère XML (mais je me trompe peut-être, dites-moi s'il vous plaît si vous n'êtes pas d'accord):
1) Si j'ai des traces de comptes d'utilisateurs organisés de cette manière
ID utilisateur 2342: Je pense qu'il est plus rapide de trouver les commentaires d'un utilisateur par chemin de fichier que de rechercher dans une grande base de données. 2) J'ai entendu MySQL est globalement verrouillé lorsque vous écrivez dessus. Est-ce vrai? Si oui, je préfère verrouiller un seul fichier que tout.
3) est MySQL "partagé" entre le cluster? Je veux dire, si 1 disque est rempli, cela "continuer" sur un autre? Ou est-ce que je dois le gérer moi-même et créer de nouvelles bases de données sur un autre disque? (Note, j'utilise Linux) 4) Notez que je ne stocke pas chaque commentaire sur les comments.xml . Je note juste leurs attributs dans chaque balise XML et les messages sont dans des fichiers texte séparés commentad.txt . Une fois que chaque XML ne devrait pas être très important, il ne devrait pas y avoir de problèmes de mémoire / temps.
Quant au problème de l'analyse du XML entier, peut-être que je devrais penser à utiliser XMLReader / Writer au lieu de SimplexML / DOM? Ou, va-t-il diminuer la performance Allot?
Merci!
/ Utilisateurs / 00/00/00/00/00/00/00 / 23/42 /
De plus, si chaque fonctionnalité est divisée dans des tables, chaque profil d'utilisateur recherchera plus d'une fois, pour afficher des commentaires, des photos, des informations de base, etc.
Il est correct que c'est à peu près la même chose en utilisant des fichiers XML, mais il est plus facile de diviser entre les disques, car la structure est divisée par des identifiants de compte, non par la fonctionnalité, comme il serait dans une base de données.
3 Réponses :
dépend fortement de la nature de votre site. D'une part, l'approche XML vous donne un laissez-passer gratuit sur des choses comme «Sélectionnez * à partir de $ Tableau où $ TABLE.ID = $ ID" Tapez les requêtes. D'autre part ...
Pour un très grand site, dans le pire des cas, les fichiers de données se terminent également. S'il s'agit d'une sorte de site communautaire, cela peut facilement se produire pour tout compte aller à n'importe quel forum avec un vrai nombre de membres de l'ancienne garde dans sa communauté et vous trouverez quelques affiches qui ont des postes de 10k ... Cela signifie que cela signifie Vous souhaiterez des ensembles de résultats de style SQL qui sont implémentés à l'aide d'un modèle efficace de mémoire, plutôt que d'une vitesse efficace. À l'utilisateur final 1S par rapport au temps de réponse 1.1S n'est pas si une affaire; mais à vous 1k de demandes simultanées contre 1,5k ou mieux est définitivement.
Ensuite, il y a l'aspect que si vous lisez principalement des données XML peut être bien si un peu brut pour les ensembles de données importants et les implémentations basées sur DOM. Mais si vous écrivez beaucoup, les choses sont beaucoup moins pires. La mise en cache de données est toujours possible, mais donnant des garanties d'acide sur ces transactions de fichiers vous oblige à écrire à peu près votre propre logiciel de base de données.
Ensuite, il existe des exigences de stockage et telles que cela signifie que vous pourriez avoir besoin d'une approche distribuée pour stocker vos données. Ce type de configurations sont relativement bien comprises dans le monde de la base de données et ils apportent beaucoup de problèmes intéressants avec eux à la table (comme ce que vous faites si un seul disque échoue ?, Comment savez-vous sur quel disque trouver les données et comment mettez-vous en œuvre une mise en cache efficace?) Cela permettra de rédiger à nouveau votre propre logiciel de mini-base de données à partir de zéro.
Donc, pour un très grand site, je pense que les exigences techniques difficiles de performance ne sont pas trop importantes en termes de mémoire et à une certaine fiabilité et à ne pas avoir besoin de réinventer 21 roues en même temps signifie que votre approche ne fonctionnerait pas si bien. Je pense qu'il est mieux adapté aux sites en lecture simples que vous pouvez vous permettre d'expérimenter et de rechercher des itinéraires alternatifs, où vous pouvez facilement apporter des modifications et les rouler sur tout le site.
IMI: une application interne utilisant un seul fichier XML pour la persistance n'a pas été utile d'utiliser un seul utilisateur ...
1) Ce que vous suggère d'être qu'un système de fichiers XML avec une application de gestionnaire ... Il existe des bases de données XML et XML dispose de la prise en charge de stocker XML au sein de la SGBDR. Vous envisagez de réinventer la roue ...
Outre la normalisation qui sortirait de stocker les données dans une SGBDM, qui appliquerait l'intégrité référentielle que XML ne fera jamais ...
2) "Verrouillage global" est sans portée contextuelle. Pas de base de données que je connais des serrures globalement lors de l'écriture; La plupart des degrés de support de verrouillage (table / rangée / etc., varient entre des fournisseurs) pour des raisons de conserver la concurrence lorsqu'il est dirigé - pas par défaut.
3) sans base de données, données ou utilisateurs réels - être préoccupé par la clustering est définitivement une optimisation prématurée.
4) Si le système se bloque sans avoir écrit l'intégrité référentielle à une sorte de persistance qui survivra à l'application éteinte, les données seront inutiles.
cela étant dit. Voici la version longue:
Je dis toujours que XML est une technologie de transfert de données, et non une technologie de stockage de données, mais pas tout le monde n'est pas d'accord. XML n'est pas conçu pour utiliser un magasin de données relationnel. XML a été introduit pour la première fois afin de fournir une manière standard de transmettre des données du système au système sans donner accès aux systèmes d'origine.
Comme vous parlez d'une application importante, je vous exhorte fortement à utiliser MySQL (ou d'autres RDBRM), car votre jeu de données augmente et augmente le XML sera de plus en plus lent et plus lent L'utilisation d'une base de données XML serait plus efficace en termes de coûts de conversion lorsque vous envoyez en permanence XML et récupérez XML hors de la base de données. La justification est, lorsque XML est la seule syntaxe de transport utilisée pour obtenir des choses dans et hors de la DB, pourquoi tout resserrer à travers une couche d'abstraction SQL et toutes ces tables relationnelles, les clés étrangères, etc. Il prend essentiellement une couche d'analyse hors de l'application et l'apporte dans le moteur de données - où il va probablement fonctionner plus rapidement et plus efficacement que l'alternative SQL. Probablement.
Je ne crois plus, CS.Cornell.edu/projects/ladis2009 /papers/lakshman-ladis2009. PDF [PDF].
@Daniel, ils utilisent Casandra en combinaison avec MySQL: facebook.com/note.php?note_id = 24413138919 de toute façon, sans utiliser XML.
Existe-t-il une raison de ne pas examiner les bases de données de documents tels que CouchDB? Ou une base de données XML existante telle que SEDNA? Cela rend beaucoup plus de sens qu'une solution exclusive XML.
"J'ai entendu ...", "Je pense ..." Vos opinions ne sont pas bien fondées - vous devez commencer à découvrir vous-même. Oui, l'accès au fichier brut est plus rapide - mais ne fournit aucun mécanisme utilisable pour la gestion de la concurrence. Les systèmes de gestion de la base de données relationnels étaient l'outil qui éliminait pratiquement des bases de données basées sur le fichier hiérarchique ("navigation") il y a 30 ans. Considérez-vous également les mérites de la langue de Cobol ou de montage sur PHP?