Sql Server Xml Colonne Meilleures pratiques

Question

Quelles sont les meilleures pratiques pour travailler avec les colonnes XML du serveur Sql afin d'assurer des performances rapides et une facilité de création de rapports?

Comment configurez-vous la colonne? le laissez-vous comme non typé? ou l'associer à un schéma?

L'association de la colonne xml à un schéma améliore-t-elle les performances des requêtes?

Notre utilisation de colonnes xml est la suivante:

A.> Sur une base client PER, nous pouvons définir le stockage flexible de leurs données sans remanier notre db. B.> Nous devons construire des vues de rapport pour chaque client qui retourne leurs données comme s'il s'agissait d'une simple table (pour les rapports Crystal ou Sql Server Reporting Services).

La syntaxe que nous utilisons actuellement à la requête est la suivante:

SELECT 
Id, 
doc.value('@associatedId','nvarchar(40)') as AssocId, 
doc.value('@name1', 'nvarchar(255)') as Name1, 
doc.value('@name2', 'nvarchar(255)') as Name2, 
doc.value('@name3', 'nvarchar(255)') as Name3, 
doc.value('@number', 'nvarchar(255)') as Number 
From OrderDetails 
CROSS APPLY OrderDetails.XmlData.nodes('//root/reviewers/reviewer') as XmlTable(doc) 

est-il un moyen plus rapide de le faire? cette requête tourne lentement pour nous dans une table avec 1 million d'enregistrements, mais seulement 800 ont actuellement des données xml!

Merci

Pete

Answer 1

De XML Best Practices for Microsoft SQL Server 2005:

Utilisez un dactylographiée ou XML typées?

Utilisez type de données XML typées sous les conditions suivantes:

• Vous n'avez pas de schéma pour vos données XML.
• Vous avez des schémas mais vous ne voulez pas que le serveur valide les données.

cela est parfois le cas quand une application effectue une validation côté client avant de mémoriser les données à le serveur, ou stocke temporairement des données XML non valide selon le schéma, ou utilise schéma XML Caractéristiques pas pris en charge sur le serveur (par exemple, key/keyref).

utilisation typée type de données XML dans les conditions suivantes:

• Vous avez des schémas pour vos données XML et que vous voulez que le serveur valider vos données XML selon le les schémas XML.
• Vous souhaitez tirer parti des optimisations de stockage et de requête basées sur les informations de type .
• Vous souhaitez tirer le meilleur parti des informations de type pendant la compilation de vos requêtes telles que les erreurs de type statique .

colonnes XML typées, des paramètres et des variables peuvent stocker des documents XML ou le contenu , que vous devez spécifier comme un drapeau (ou DOCUMENT DE CONTENU, respectivement) au moment de la déclaration . En outre, vous devez fournir un ou plusieurs schémas XML. Spécifiez DOCUMENT si chaque instance XML a exactement un élément de niveau supérieur; Sinon, utilisez le CONTENT. La requête compilateur utilise l'indicateur DOCUMENT dans le type vérifie lors de la compilation de la requête à infer singleton éléments de niveau supérieur.

L'association de la colonne xml à un schéma améliore-t-elle les performances des requêtes? Voir ci-dessus point: utilisez tapé XML si vous voulez tirer parti des optimisations de requête en fonction des informations de type.

Il y a aussi une longue discussion sur les avantages des index XML:

Votre application peut bénéficier d'un index XML dans les conditions suivantes:

• Les requêtes sur les colonnes XML sont communes dans votre charge de travail. Le coût de maintenance de l'index XML lors de la modification des données doit être pris en compte.
• Vos valeurs XML sont relativement grandes et les parties récupérées sont relativement petites. La construction de l'index évite l'analyse de toutes les données au moment de l'exécution et profite aux recherches d'index pour un traitement efficace des requêtes.

Et surtout, l'index XML secondaire type de approprié pour votre utilisation:

• Si votre charge de travail utilise des expressions de chemin fortement sur des colonnes XML, l'index XML secondaire PATH est susceptible d'accélérer votre charge de travail. Le cas le plus courant est l'utilisation de la méthode exist() sur les colonnes XML dans la clause WHERE de Transact-SQL.
• Si votre charge de travail extrait plusieurs valeurs d'instances XML individuelles à l'aide d'expressions de chemin, des chemins de cluster dans chaque instance XML dans l'index PROPERTY peuvent être utiles. Ce scénario se produit généralement dans un scénario de sac de propriétés lorsque les propriétés d'un objet sont récupérées et que sa valeur de clé primaire relationnelle est connue.
• Si votre charge de travail implique l'interrogation de valeurs dans des instances XML sans connaître les noms d'élément ou d'attribut qui contiennent ces valeurs, vous pouvez créer l'index VALUE. Cela se produit généralement avec des recherches d'axes descendants, tels que //author[last-name="Howard"], où <author> éléments peuvent se produire à n'importe quel niveau de la hiérarchie et la valeur de recherche ("Howard") est plus sélective que le chemin. Il se produit également dans les requêtes "génériques", telles que /book [@* = "novel"], où la requête recherche <book> éléments avec un attribut ayant la valeur "novel".

Answer 2

Si comme dans l'exemple ci-dessus, vous utilisez le XML pour stocker différentes colonnes de chaîne, je ne pense pas que vous voulez vraiment profiter de XML typé, sauf si vous avez un besoin pour le serveur pour valider les données. En ce qui concerne les performances, je pense que ce serait plus rapide, non typé.

Pour ces types de requêtes, vous devez absolument avoir des index XML en place, ils sont essentiels pour une bonne performance des requêtes XML. Sans index, les colonnes XML sont stockées en tant que blobs. Pour les interroger, SQL doit d'abord décomposer le blob en XML, puis effectuer les opérations demandées. Un index XML principal stocke le code XML déchiqueté dans la base de données, de sorte qu'il n'est pas nécessaire de le faire à la volée. Vous devez d'abord créer un index XML principal, puis des index XML secondaires peuvent être créés pour prendre en charge vos requêtes.

Il existe 3 types d'index XML secondaires: PATH, VALUE et PROPERTY. Les index secondaires dont vous avez besoin dépendent du type de requêtes que vous allez effectuer. Je vous encourage donc à consulter la rubrique Secondary XML Indexes de la documentation en ligne pour déterminer laquelle vous sera utile: http://msdn.microsoft.com/en-us/library/bb522562(SQL.100).aspx