(Cet article sollicite des expériences personnelles de stocker XML; veuillez partager ce que vous savez. :-))
Je travaille sur une application de service qui communique avec un service externe utilisant XML. Je prévois d'utiliser SQL Server 2008 pour stocker le XML reçu et envoyé au service externe. J'explore mes options pour stocker le XML dans la base de données. Les trois options que j'ai identifiées sont:
Je recherche des conseils, basés sur votre expérience personnelle, avec stocker et récupérer des données XML dans SQL Server.
Quelques fond supplémentaires: j'ai utilisé un '' xsd.exe ' équivalent appelé XsdObjectGenerator pour créer des classes .NET basées sur le XML schémas. Lorsque le service reçoit le fichier XML, il est désérialisé dans une instance de classe .NET. Cette instance est utilisée pour effectuer les opérations du service. Mon plan initial était d'utiliser l'option 1 ci-dessus pour stocker le XML. Si je devais mettre à jour ou signaler les données, je désérialiserais simplement le record de DB dans l'une de mes classes .net.
Bien que cette approche fonctionne et fait travailler avec le XML très simple, je crains que, comme le volume des données augmente, les performances d'interrogation des enregistrements de type de données XML diminueront. C'est pourquoi j'ai exploré les options 2. & 3. ci-dessus.
En plus de stocker le XML, le XML sera interrogé pour une utilisation dans les deux rapports et une application Web distincte. Les enregistrements DB seront interrogés, triés, filtrés, groupés, résumés et éventuellement mis à jour par les utilisateurs finaux.
3 Réponses :
Je suppose que cela dépend de ce que vous voulez faire avec votre XML dans votre base de données.
Si vous ne le stockez principalement que et éventuellement la récupérer plus tard dans son ensemble et que je l'envoie à nouveau, j'utiliserais certainement le type de données XML - aucun point de la déchiquetage en morceaux et en morceaux.
Si vous avez toutefois besoin de travailler surtout avec le contenu du fichier XML, et peut également manipuler et modifier ce contenu, il peut être souhaitable de créer des tables avec des colonnes pour correspondre à votre contenu XML et de la déchiqueter lorsque vous le stockez, Utilisez-le, et lorsque vous devez, réassemblez-le des pièces relationnelles à l'aide de quelque chose comme Il y a une surcharge impliquée dans le déchiquetage et le réassemblage - vous devez donc vous demander si cela vaut la peine de faire. Mais il y a aussi une surcharge impliquée si vous avez besoin de manipuler trop la colonne XML.
Si vous n'avez besoin que d'un accès en lecture seule à quelques attributs de votre XML, je suis venu à apprécier la possibilité de les envelopper dans un UDF et de la surface en tant que colonne calculée de votre table. De cette façon, vous pouvez facilement sélectionner quelque chose dans votre table, en fonction des valeurs stockées quelque part dans votre XML - tout à fait pratique! Mais n'utilisez pas cette approche - fonctionne bien pour 2, 3 attributs - mais si vous avez besoin d'accéder à votre XML encore et encore (et le plus ou tout), vous pourriez peut-être mieux le déchiqueter en morceaux relationnels. . Sélectionnez (Colonnes) à partir de DBO.table pour XML .....
Merci pour votre réponse utile.
Tout en continuant à explorer des solutions, un collègue transféra les liens applicables suivants:
Certaines conclusions préliminaires de ces articles et autres recherches:
Je vais vous moquer de chaque solution avec des données de test et effectuer une analyse comparative. Je posterai les résultats ici une fois qu'ils sont disponibles.
Quelques tâches Retour (SQL 2000), nous stockions XML comme des données texte, et nos bases de données sont devenues ballonnées de manière significative - pas tellement avec les données que les balises utilisées pour l'identifier. J'ai fait des tests, et Pkzip (j'ai dit que c'était de plusieurs travaux, il y a plusieurs travaux) toutes les données jusqu'à 3% de sa taille d'origine.
Conseil n ° 1: Identifiez la durée pendant laquelle vous devez stocker les données, et si / lorsque vous archivez les anciennes données anciennes.
Conseil n ° 2: Si vous utilisez SQL 2008, examinez les options de compression de données pour les colonnes XML.
(Pourrait ne pas être pertinent si vos XML sont courts, mais les nôtres étaient tous dans les KB et 10kbs.)
Je définirais plus clairement les intentions de la "DB" Logging DB ". Cela ressemble beaucoup à ce que vous devriez simplement stocker la zippée de XML dans un répertoire et avoir ceci comme retombe, lorsque vous souhaitez effectuer des rapports sur eux. Il est également extrêmement facile de sauvegarder ces fichiers ou de les déplacer du système en direct, que d'exporter des parties d'une DB.
Merci pour votre commentaire. J'ai ajouté des détails supplémentaires ci-dessus.