Quand dois-je utiliser le type de données XML dans SQL Server?

Quand dois-je utiliser le type de données XML dans Microsoft SQL Server?

J'ai fait une chose similaire où je sérialise les données d'objet en XML pour le stockage. Cela supprime le fardeau d'avoir des tables, des colonnes et des relations en place pour stocker les données des objets complexes. Le processus peut être aidé en utilisant un schéma auquel le résultat XML est conforme et les tables de base de données peuvent être utilisées pour des méta-informations sur les objets en question. Dans mon cas, étendre le schéma de la base de données pour s'adapter à la disposition des objets serait une grosse tâche!

Personnellement, je n'ai jamais utilisé le type de champ XML dans SQL Server auparavant, et j'ai fait beaucoup de programmation de base de données depuis qu'ils ont ajouté cette fonctionnalité. Il m'a toujours semblé qu'il y avait une surcharge de programmation et de performances pour utiliser nativement du contenu XML dans une base de données. Honnêtement, je pensais que c'était un gadget, car tout le monde était dans le train XML à un moment donné au début des années 2000. "Oh XML est chaud, alors ajoutons-le à SQL Server pour ne pas avoir l'air dépassé."

La meilleure analyse de rentabilisation que je puisse voir pourrait consister à enregistrer les messages de données basés sur XML que vous avez reçus, où vous voudrez peut-être jeter un œil à leur structure et à leurs données, mais souhaitez conserver l'intégrité du message d'origine pour des raisons commerciales ou juridiques. La surcharge peut être trop importante pour traduire le XML en une structure de table, mais l'utilisation des capacités XML dans SQL Server peut simplement réduire le coût de l'examen des données suffisamment pour justifier son utilisation.

Il y a probablement des dizaines d'autres raisons pour lesquelles vous voudriez l'utiliser, mais franchement, je pense que vous devriez envisager d'autres chemins vers le bonheur avant de vous lancer dans XML avec SQL Server sauf si vous avez des raisons commerciales très spécifiques de le faire. Utilisez un varchar (max) ou un champ de texte si cela a plus de sens.

Juste mon avis bien sûr :)

Je n'ai rencontré que quelques scénarios où je poursuivrais activement l'utilisation du type de données XML dans SQL Server. C'est du haut de ma tête, du moins au plus intéressant:

• Stockage / archivage des réponses XML générées par d'autres applications
  • Par exemple, nous utilisons Application Integration Framework (AIF) pour communiquer entre une application Silverlight personnalisée et Dynamics AX. Nous stockons les messages entrants et sortants dans la base de données pour faciliter le dépannage de la communication entre ces applications
  • Étant donné que le type de champ est XML plutôt qu'un type de chaîne générique (c'est-à-dire VARCHAR), nous pouvons utiliser XQuery pour rechercher spécifiquement des messages correspondant à certains critères spécifiques. Ce serait beaucoup plus difficile avec une simple chaîne LIKE matching
• Mise en cache / persistance d'un message de réponse composé
  • Mettre à jour le champ XML avec un déclencheur ou un code d'application, qui imiterait une colonne calculée
  • Au lieu de régénérer constamment une réponse XML à une application appelante, vous n'encourriez de surcharge que lorsque la ligne est inversée, plutôt qu'à chaque appel
  • Cela fonctionne mieux lorsque les SELECT sont beaucoup plus fréquents que les UPDATE / INSERT, ce qui a tendance à être vrai pour la plupart des applications.
• Stockage de plusieurs valeurs dans un seul champ
  • L'une des pratiques que j'ai vues est l'utilisation du type de données XML pour stocker une collection de valeurs dans un seul champ
  • Un avantage est que vous n'avez pas besoin de concevoir un ensemble supplémentaire de tables pour un simple magasin de clés / valeurs
  • Un inconvénient est que les données ne sont pas entièrement normalisées, ce qui rend les requêtes moins évidentes
  • Cependant, comme mentionné ci-dessus, vous pouvez utiliser XQuery sur ce champ XML pour sélectionner des lignes qui correspondent aux critères d'identification, nuétalisant ainsi partiellement l'impact de la non-normalisation complète.

Cela dit, 99% du temps, je n'ai absolument pas besoin d'un champ XML lors de la conception d'un schéma.

Les quelques fois où j'ai vu le type de données XML dans SQL Server, il a essentiellement été utilisé comme un champ qui a été interrogé comme tout autre dans la base de données, ce qui peut avoir de très mauvaises implications en termes de performances si vous avez une grande quantité de données . Il y a une raison pour laquelle on l'appelle serveur SQL et non serveur XML. :-) Les requêtes qui vont à l'encontre du XML ne sont tout simplement pas aussi rapides qu'une requête de sélection régulière.

Je pouvais voir qu'il était utilisé pour stocker du XML qui n'est pas beaucoup interrogé, par exemple, stocker le document XML complet dans un type de données XML, mais avoir les champs consultables (clés) stockés séparément avec le document XML. De cette façon, vous pouvez interroger vos informations plus rapidement et afficher le document XML lorsque vous arrivez au point où vous souhaitez voir le document complet. J'ai en fait dû revenir en arrière et le faire avec un certain nombre d'applications où les gens ont essayé d'utiliser le type de données XML comme champ fortement interrogé et les données ont augmenté au point où la requête est devenue trop lente.

J'ai utilisé des champs de type XML principalement à des fins de journalisation liées aux services Web ASMX ou aux services WCF. Vous pouvez enregistrer la demande ou les messages de réponse.

La plupart du temps, vous enregistrez le XML dans la base de données à des fins de référence - pas pour votre activité commerciale normale (pour ne pas l'interroger toutes les 5 secondes à partir du code). Si vous vous y trouvez, déterminez les champs que vous interrogez ou utilisez le plus souvent et créez des colonnes distinctes pour eux. De cette façon, lorsque vous enregistrez le XML dans la base de données, vous pouvez extraire ces champs et les enregistrer dans leurs colonnes correspondantes. Plus tard, lors de leur récupération, vous n'aurez pas besoin d'interroger le document XML, vous pouvez simplement utiliser les colonnes que vous avez créées à cet effet.

Voici les scénarios qui vous viennent immédiatement à l'esprit lorsque vous envisagez les conditions qui devraient exister pour autoriser les champs Xml dans Sql Server:

• données binaires codées pour l'échange où vous voulez un contrôle acide de la ressource
• des fragments de documents qui seront reconstitués dans leur ensemble à l'aide d'informations dynamiques
• les documents ou fragments soumis par l'utilisateur que vous souhaitez isoler et, au moins provisoirement, empêcher directement le système de fichiers.

J'utilise beaucoup XML dans les applications client-serveur pour enregistrer des données structurées en un seul appel à la base de données. Par exemple, prenez une facture avec des lignes de détail. Il est simple de demander au client de sérialiser l'objet métier en XML et de le passer à un proc stocké en un seul appel. Le proc décide si une insertion ou une mise à jour est requise; il peut obtenir l'ID de facture parent (une colonne d'identité) à affecter aux enregistrements de détail, le tout dans une transaction côté serveur et sans que le client n'ait à effectuer plusieurs allers-retours. Je n'ai pas besoin d'environ 20 paramètres pour spécifier l'enregistrement d'en-tête et je n'ai pas besoin d'appeler pour chaque ligne de facture. De plus, il est souvent possible d'apporter des modifications au schéma ou d'introduire la journalisation / l'audit sans avoir à toucher le client.