3

迅速なパフォーマンスとレポートの容易さを確保するために SQL サーバーの Xml 列を操作するためのベスト プラクティスは何ですか?

カラムをどのように設定しますか? 型なしのままにしますか？またはそれをスキーマに関連付けますか？

xml 列をスキーマに関連付けると、クエリのパフォーマンスが向上しますか?

xml 列の使用方法は次のとおりです。

A.> お客様ごとに、データベースをオーバーホールすることなく、データの柔軟なストレージを定義できます。

B.> 単純なテーブル (Crystal Reports または Sql Server Reporting Services の場合) であるかのようにデータを返すレポート ビューを顧客ごとに作成する必要があります。

現在クエリに使用している構文は次のとおりです。

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)

これを行うより速い方法はありますか？このクエリは、100 万のレコードを持つテーブルでゆっくりと実行されますが、現在 xml データを持っているのは 800 だけです!

ありがとう

ピート

4

2 に答える 2

5

Microsoft SQL Server 2005のXMLベストプラクティスから：

型付きまたは型なしのXMLを使用しますか？

次の条件下では、型指定されていないXMLデータ型を使用します。

  • XMLデータのスキーマがありません。
  • スキーマはありますが、サーバーにデータを検証させたくありません。

これは、アプリケーションがサーバーにデータを保存する前にクライアント側の検証を実行したり、スキーマに従って無効なXMLデータを一時的に保存したり、サーバーでサポートされていないXMLスキーマ機能（ key/などkeyref）を使用したりする場合に発生します。

次の条件下で、型付きXMLデータ型を使用します。

  • XMLデータのスキーマがあり、サーバーがXMLスキーマに従ってXMLデータを検証するようにします。
  • タイプ情報に基づいたストレージとクエリの最適化を利用したいと考えています。
  • 静的タイプエラーなどのクエリのコンパイル中に、タイプ情報をより有効に活用する必要があります。

型指定されたXML列、パラメーター、および変数は、宣言時にフラグ（それぞれ、DOCUMENTまたはCONTENT）として指定する必要があるXMLドキュメントまたはコンテンツを格納できます。さらに、1つ以上のXMLスキーマを提供する必要があります。各XMLインスタンスに最上位要素が1つだけある場合は、DOCUMENTを指定します。それ以外の場合は、CONTENTを使用します。クエリコンパイラは、クエリのコンパイル中に型チェックでDOCUMENTフラグを使用して、シングルトンの最上位要素を推測します。

xml列をスキーマに関連付けると、クエリのパフォーマンスが向上しますか？上記のポイントを参照してください。型情報に基づくクエリの最適化を利用する場合は、型付きXMLを使用してください。

XMLインデックスの利点についても長い議論があります。

アプリケーションは、次の条件下でXMLインデックスの恩恵を受ける可能性があります。

  • XML列のクエリは、ワークロードで一般的です。データ変更中のXMLインデックスの保守コストを考慮する必要があります。
  • XML値は比較的大きく、取得される部分は比較的小さいです。インデックスを作成すると、実行時にデータ全体を解析する必要がなくなり、効率的なクエリ処理のためにインデックスルックアップにメリットがあります。

そして最も重要なのは、使用法に適したタイプのセカンダリXMLインデックスです。

  • ワークロードがXML列でパス式を多用する場合、PATHセカンダリXMLインデックスによってワークロードが高速化される可能性があります。最も一般的なケースは、Transact-SQLの句でexist()XML列にメソッドを使用することです。WHERE
  • PROPERTYワークロードがパス式を使用して個々のXMLインスタンスから複数の値を取得する場合、インデックス内の各XMLインスタンス内のパスをクラスタリングすると役立つ場合があります。このシナリオは通常、オブジェクトのプロパティがフェッチされ、そのリレーショナル主キー値がわかっている場合に、プロパティバッグシナリオで発生します。
  • ワークロードに、それらの値を含む要素または属性名を知らずにXMLインスタンス内の値を照会することが含まれる場合は、VALUEインデックスを作成することをお勧めします。これは通常、などの子孫軸ルックアップで発生します。この場合//author[last-name="Howard"]、<author>要素は階層の任意のレベルで発生する可能性があり、検索値("Howard")はパスよりも選択的です。また、などの「ワイルドカード」クエリでも発生します。このクエリでは、値が。の属性を持つ要素が/book [@* = "novel"]検索されます。<book>"novel"
于 2010-08-21T00:40:21.177 に答える
2

上記の例のように、XMLを使用してさまざまな文字列列を格納している場合、サーバーがデータを検証する必要がない限り、型付きXMLのメリットはあまりないと思います。パフォーマンスの面では、型指定されていない方が速いと思います。

これらの種類のクエリでは、XMLインデックスを配置する必要があります。これらは、XMLクエリのパフォーマンスを向上させるために不可欠です。インデックスがない場合、XML列はblobとして格納されるため、それらをクエリするには、SQLは最初にblobをXMLに細断処理してから、要求する操作を実行する必要があります。プライマリXMLインデックスは、細断されたXMLをデータベースに格納するため、オンザフライで実行する必要はありません。最初にプライマリXMLインデックスを作成する必要があります。次に、クエリをサポートするためにセカンダリXMLインデックスを作成できます。

セカンダリXMLインデックスには、PATH、VALUE、PROPERTYの3種類があります。必要なセカンダリインデックスは、実行するクエリの種類によって異なるため、Books OnlineのセカンダリXMLインデックスのトピックを確認して、どのセカンダリインデックスが役立つかを判断することをお勧めします 。http：/ /msdn.microsoft.com/en-us/library/bb522562(SQL.100).aspx

于 2010-08-21T01:30:18.730 に答える