Le type de données XML SQL Server 2008 présente-t-il des problèmes de performances?

Salut J'ai besoin de stocker des centaines sinon des milliers d'éléments dans la database en XML. Je n'indexerai rien dans le champ XML. Je vais simplement sélectionner certains éléments dans le xml. Je voudrais savoir s'il y a une pénalité de performance pour simplement sélectionner des champs dans le XML. Voici un exemple de XML qui sera stocké dans la database.

<fields> <field name="FirstName" type="text" value="Gary" sort="2" /> <field name="LastName" type="text" value="Smith" sort="3" /> <field name="City" type="text" value="Los Angeles" sort="4" /> <field name="Age" type="number" value="12" sort="6" /> <field name="Address" type="text" sort="2"> <streetnumber value="1234" /> <streetname value="sail" /> </field> </fields> 

Je vais probablement avoir plus de 3000 labels de terrain dans un logging. Je veux simplement get 10 champs dans une seule requête. J'aurai une key primaire sur la table et je sélectionnerai des loggings basés sur la key primaire, mais j'obtiendrai des champs de la colonne XML. J'ai peur que plus les éléments de champ que je mets dans le XML compromettront les performances. Y aura-t-il une pénalité de performance pour simplement sélectionner 10 champs ou plus dans la colonne XML? Aussi, je n'utiliserai pas la colonne xml dans une clause where j'utiliserai le primaire dans la clause where puis je sélectionnerai les champs de la colonne XML. Y aura-t-il une pénalité de performance?

Basé sur mon expérience sur XML dans le type de données SQL Server Xml et sur les index sur les colonnes de type de données XML (toute la section mérite une lecture approfondie)

Y aura-t-il une pénalité de performance pour simplement sélectionner 10 champs ou plus dans la colonne XML?

Oui, car votre document XML est stocké sous forme de blob. Sans un index XML primaire, ce blob devra être exploré pour le traitement des requêtes (filtrage et projection). En XML, les index peuvent être vus comme une représentation relationnelle de votre document (pré-explosion du blob)

Sans index, ces objects volumineux binarys sont déchiquetés au moment de l'exécution pour évaluer une requête. Ce déchiquetage peut prendre beaucoup de time

Quant à votre deuxième question

Aussi, je n'utiliserai pas la colonne xml dans une clause where j'utiliserai le primaire dans la clause where puis je sélectionnerai les champs de la colonne XML. Y aura-t-il une pénalité de performance?

Si vous projetez parmi les 3000 balises de champ, vous pourriez bénéficier d'un index XML secondaire, même si je ne suis pas sûr de savoir lequel. L'index secondaire PROPERTY semble apte à la projection, mais il semble s'appliquer aux appels de value (la documentation française semble impliquer plus que des appels de value mais cela peut être une erreur de traduction)

Pour ma part, j'ai fini par définir les trois types d'index secondaires sur ma colonne XML (1 million de documents sur 30 schémas différents, 50-100 éléments chacun) Mais mon application nécessite beaucoup plus de filtrage que de projection.

[BEGIN EDIT]
Les réponses directes de jbl à vos questions, et la réponse de Terror.Blade au fait que XML soit meilleur que NVARCHAR (MAX) ont du sens (je les ai mises à jour :).

Mon expérience était sans stocker un schéma XML dans SQL Server (truc de Terror.Blade), et sans indexing (jbl a donné le plus, re 'ça) … mais je laisse ma réponse, car je pense que mes liens pourraient être très utile … et c'est toujours un exemple du pire des cas;)
[END EDIT]

D'expérience, je dirai que le chargement d'un type de données XML est rapide, mais quant à son utilisation, je trouve que c'est lent, mais l'exemple personnel qui vient à l'esprit implique la mise à jour et l'utilisation de xQuery. été des facteurs dans mon ralentissement. Dans cet exemple, il a fallu 1hr55mins pour traiter seulement 127 861 lignes. (L'astuce de Terror.Blade, de stocker un schéma XML dans SQL Server, et le lien et le partage de jbl sur l'indexing XML sont tous deux assez sournois;) et pourrait résoudre ce ralentissement.)

CONNEXES : Voici quelques conseils pour optimiser XML en SQL … même si certains d'entre eux ne s'appliquent que si vous avez le contrôle sur le format XML:
http://msdn.microsoft.com/en-us/library/ms345118.aspx

Si vous utilisez xQuery, consultez ces documents:
http://download.microsoft.com/download/0/F/B/0FBFAA46-2BFD-478F-8E56-7BF3C672DF9D/XQuery%20Language%20Reference.pdf

((Et si vous utilisez SQLXMLBulkLoad du tout, pensez à utiliser "overflow-field" s, pour capturer tout ce qui n'est pas défini dans votre schéma.Il y a quelques conseils utiles dans cette TechNote tangentiellement connexe :
http://social.technet.microsoft.com/Forums/sqlserver/en-US/393cf604-bf6e-488b-a1ea-2e984aa14500/how-do-i-redirect-xml-comments-that-sqlxmlbulkload-is-storing- dans-le-overflowfield? forum = sqlxml ))

HTH.