XML データ型と列 (SQL Server)
適用対象:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
このトピックでは、SQL Server での xml データ型を使用する利点と制限や、XML データを保存する方法の正しい選択に役立ちます。
リレーショナル または XML データ モデル
使用するデータが既知のスキーマにより十分に構造化されている場合、データ ストレージとしてはリレーショナル モデルが最適です。 SQL Serverは、必要な機能とツールを提供します。 ただし、データが構造化されていないか構造化が部分的である場合、または構造化の状態が不明な場合は、データのモデリングを検討する必要があります。
構造や意味によるマークアップを行ってデータを移行できるようにするために、プラットフォームに依存しないモデルが必要な場合、XML が適しています。 また、次に示す条件に該当する場合も XML が適切です。
データの密度が低いか構造が不明な場合。または将来のデータの構造が大きく変わる可能性がある場合。
データがエンティティ間の参照ではなく包含階層を成していて、再帰的な性質がある場合。
データの順序が固定している場合。
データの構造を基にして、データへのクエリやデータの部分的な更新を行う場合。
上記の条件のいずれにも該当しない場合は、リレーショナル データ モデルを使用してください。 たとえば、データが XML 形式であってもデータの格納と取得にしかデータベースを使用しない場合、 [n]varchar(max) 列で十分です。 XML 列にデータを格納すると、それ以外の利点があります。 たとえば、データが適切な形式であり有効であることをデータベース エンジンで判断できることや、XML データに対するきめ細かいクエリや更新がサポートされることなどです。
SQL Server で XML データを保存する理由
次に、ファイル システムによる XML データの管理ではなく、SQL Server のネイティブ XML 機能を使用する理由を示します。
XML データの共有、クエリ、および変更をトランザクション方式で効率的に行うため。 アプリケーションにとって、きめ細かいデータ アクセスは重要です。 たとえば、XML ドキュメントのセクションの一部を抽出したり、ドキュメント全体を置き換えることなく新しいセクションを挿入することができます。
リレーショナル データと XML データがあり、アプリケーションで双方のデータ間の相互運用性が必要なため。
XML とリレーショナルの 2 つの領域にまたがるアプリケーションで、クエリやデータ変更に対する言語サポートが必要なため。
データが整形式であることの保証、および必要に応じて XML スキーマに従ったデータの検証をサーバーで行うため。
クエリの処理を効率化し、スケーラビリティを高めるため XML データにインデックスを設定し、特に優れたクエリ オプティマイザーを使用するため。
SOAP、ADO.NET、および OLE DB で XML データにアクセスするため。
XML データの管理にデータベース サーバーの管理機能を使用するため。 たとえば、バックアップ、復旧、およびレプリケーションなどです。
上記の条件のいずれにも該当しない場合、XML 以外のラージ オブジェクト型 ( [n]varchar(max) 、 varbinary(max)など) でデータを保存するのが適切です。
XML ストレージ オプション
次に、SQL Server での XML のストレージ オプションを示します。
xml データ型としてのネイティブ ストレージ
データの XML コンテンツを保持できる内部表現を使用してデータが保存されます。 内部表現には、包含階層、表示順、要素や属性の値に関する情報などがあります。 具体的には、XML データの InfoSet コンテンツが保持されます。 InfoSet の詳細については、「http://www.w3.org/TR/xml-infoset」を参照してください。 InfoSet コンテンツでは、重要でない空白文字、属性の順序、名前空間プレフィックス、および XML 宣言が保持されないので、テキスト形式の XML のまったく同一のコピーにはならない場合があります。
型指定された xml データ型、つまり XML スキーマにバインドされた xml データ型の場合、PSVI (スキーマ検証後の InfoSet) によって型情報が InfoSet に追加され、内部表現にエンコードされます。 その結果、解析速度が大幅に向上します。 詳細については、http://www.w3.org/TR/xmlschema-1 と http://www.w3.org/TR/xmlschema-2 で W3C の XML スキーマの仕様を参照してください。
XML ストレージとリレーショナル ストレージのマッピング
AXSD (注釈付きスキーマ) を使用することで、XML は 1 つ以上のテーブルの複数の列に分解されます。 分解されても、リレーショナル レベルでのデータの忠実性は保たれます。 したがって、要素間の順序は無視されますが階層構造は保持されます。 再帰的なスキーマは使用できません。
ラージ オブジェクト ストレージ、 [n]varchar(max) と varbinary(max)
データの完全なコピーが保存されます。 これは、法務文書など、特殊な用途に使用します。 ほとんどの場合、正確なコピーは不要であり、XML コンテンツ (InfoSet レベルの忠実性) で十分です。
一般的には、上記のいくつかの方法を組み合わせることができます。 たとえば、 xml データ型の列に XML データを保存して、列のプロパティをリレーショナル列に昇格させることができます。 または、再帰しない部分を XML 以外の列に格納し、再帰部分のみを xml データ型の列に格納するためにマッピング テクノロジを使用することができます。
XML テクノロジの選択
ネイティブ XML と XML ビューのどちらの XML テクノロジを選択するかは、主に次の要因によって決まります。
ストレージ オプション
XML データは、ラージ オブジェクトとして保存するのが適切な場合 (製品マニュアルなど) と、リレーショナル列に保存するのに向いている場合 (XML に変換した商品品目など) があります。 それぞれのストレージ オプションで保持される忠実性の度合いが異なります。
クエリ機能
クエリの性質およびクエリの対象になる XML データの範囲を基に、最適なストレージ オプションがわかる場合があります。 XML ノードの述語評価など、XML データへのきめ細かいクエリは、2 つのストレージ オプションでのサポートの度合いに差があります。
XML データのインデックス設定
XML クエリのパフォーマンスを向上するために、XML データにインデックスを設定できます。 インデックス設定のオプションはストレージ オプションによって異なります。ワークロードを最小にするために、適切な選択を行う必要があります。
データ変更機能
一部のワークロードは、XML データのきめ細かい変更を伴います。 たとえば、ドキュメント内に新しいセクションを追加する場合などが該当しますが、Web コンテンツなどのその他のワークロードではこのような変更はありません。 アプリケーションで、データ変更言語のサポートが重要になる場合があります。
スキーマのサポート
XML データは、スキーマを使用して記述できる場合があります。このときのスキーマは、XML スキーマ ドキュメントであっても、そうでなくてもかまいません。 スキーマにバインドされた XML がサポートされるかどうかは、XML テクノロジによって異なります。
どの選択肢を選ぶかで、パフォーマンス特性が異なります。
ネイティブ XML ストレージ
XML データを、サーバーの xml データ型の列に保存できます。 次の条件に該当する場合、この方法が適しています。
簡単にサーバーに XML データを保存すると同時に、表示順やドキュメント構造を保持する場合。
XML データのスキーマがあるかどうかが明確でない場合。
XML データに対し、クエリや変更を行う場合。
クエリ処理を高速化するために XML データにインデックスを設定する場合。
XML データと XML スキーマを管理するためのシステム カタログ ビューが必要な場合。
構造が多様な XML ドキュメントがある場合、またはリレーショナル構造へのマッピングが難しい複雑なスキーマや複数のスキーマに従った XML ドキュメントがある場合に、ネイティブ XML ストレージが役立ちます。
例 : xml データ型を使用した XML データ モデリング
トピックごとに章が設けられ、それぞれの章の中には複数の節がある構成の XML 形式の製品マニュアルを考えてみます。 節には項が含まれる場合があります。 したがって、<section> は再帰要素になります。 製品マニュアルには、混合コンテンツ、図表、および技術データが大量に含まれているので、データは部分的に構造化された状態です。 ユーザーは、「インデックス設定」に関する章の「クラスター化インデックス」に関する節を検索するなど、関心のあるトピックをコンテキストにより検索したり、技術データにクエリを実行します。
この XML ドキュメントに適したストレージ モデルは xml データ型列です。 このモデルであれば、XML データの InfoSet コンテンツが保持されます。 XML 列にインデックスを設定して、クエリ パフォーマンスを向上できる利点もあります。
例 : XML データの正確なコピーの保持
たとえば、政府の規定により、XML ドキュメントのテキストの正確なコピーを保持する必要があるとします。 署名済み文書、法務文書、株取引の注文書などが該当します。 このようなドキュメントは [n]varchar(max) 列に保存できます。
クエリを行うには、実行時にデータを xml データ型に変換して XQuery を実行します。 実行時の変換は、ドキュメントが大きい場合は特にコストが高くなる可能性があります。 頻繁にクエリを実行する場合は、 xml データ型の列にドキュメントを冗長に保存してインデックスを設定しておき、 [n]varchar(max) 型の列からドキュメントの正確なコピーを返すことができます。
XML 列は [n]varchar(max) 型の列を基にした計算列にすることができます。 ただし、XML 計算列に XML インデックスを作成すること、および [n]varchar(max) 型または varbinary(max) 型の列に XML インデックスを作成することはできません。
XML ビュー テクノロジ
XML スキーマとデータベース内のテーブルとのマッピングを定義することで、永続的なデータの XML ビュー を作成します。 XML ビューを使用して基になるテーブルのデータを格納する場合に、XML 一括読み込みを行うことができます。 XML ビューには XPath Version 1.0 を使用してクエリを実行できます。テーブルでクエリが実行されるときには SQL クエリに変換されます。 これと同様に、更新もテーブルに反映されます。
このテクノロジは、次のような場合に役立ちます。
既存のリレーショナル データの XML ビューを使用した XML 中心のプログラミング モデルが必要な場合。
外部のパートナーから提供された XML データのスキーマ (XSD、XDR) がある場合。
データの順序が重要ではない場合、クエリ テーブル データが再帰的でない場合、または事前に再帰の最大の深さがわかっている場合。
XPath Version 1.0 を使用して、XML ビューからデータに対するクエリや変更を行う場合。
XML ビューを使用し、XML データの一括読み込みを行ってそれを基になるテーブルに分解する場合。
例としては、データ交換や Web サービス向けに XML として公開されたリレーショナル データ、固定スキーマにバインドされた XML データなどがあります。 詳しくは、
例 : 注釈付き XML スキーマ (AXSD)を使用したデータ モデリング
たとえば、顧客、注文、品目などの既存のリレーショナル データを XML として処理するとします。 リレーショナル データに AXSD を使用して、XML ビューを定義します。 XML ビューを使用すると、テーブルに XML データを一括で読み込み、XML ビューでリレーショナル データに対するクエリや更新を行うことができます。 SQL アプリケーションの実行を中断することなく、XML でマークアップされたデータを他のアプリケーションと交換する必要がある場合に、このモデルが役立ちます。
ハイブリッド モデル:
リレーショナル列と xml データ型の列を組み合わせることがデータ モデリングとして適している場合も多くあります。 XML データの値の一部をリレーショナル列に保存し、残り (または XML 値全体) を XML 列に保存することができます。 そうすることで、リレーショナル列に作成したインデックスやロック特性を制御しやすくなり、パフォーマンスが向上する場合があります。
リレーショナル列に保存する方が適切な値はワークロードによって異なります。 たとえば、パス式 を基にすべての XML 値を取得する場合、/Customer/@CustId属性の値をリレーショナル列にCustId昇格してインデックスを設定することにより、クエリ パフォーマンスが向上する可能性があります。 一方で、XML データが冗長性なしで多数のリレーショナル列に分解されている場合、再構成のコストが甚大になる可能性があります。
テーブルのコンテンツを XML に変換した場合など、十分に構造化された XML データでは、すべての値をリレーショナル列にマップすることができ、XML ビュー テクノロジを使用できる場合もあります。
XML データの粒度
XML 列に保存される XML データの粒度は、ロックの際に重要であるだけでなく、更新の際にも重要です。 SQL Serverでは、XML データと XML 以外のデータに対して同一のロック メカニズムを使用します。 したがって行レベルのロックを設定すると、行内のすべての XML インスタンスがロックされます。 粒度が粗い場合、マルチユーザー シナリオで更新のために大きな XML インスタンスをロックすると、スループットが低下します。 一方、分割しすぎるとオブジェクトのカプセル化状態が失われ、再構成のコストが上がります。
優れた設計を行うには、データ モデリングの要件とロックや更新の特性との間でバランスを取ることが重要です。 ただし SQL Serverでは、実際に保存される XML インスタンスのサイズが決定的な要因になることはありません。
たとえば、新旧の XML インスタンスの比較による BLOB (バイナリ ラージ オブジェクト) やインデックスの部分更新が新しくサポートされるようになったので、それにより XML インスタンスが更新されます。 BLOB (バイナリ ラージ オブジェクト) の部分更新は、2 つの XML インスタンスの差異を比較して差分のみを更新します。 インデックスの部分更新は、XML インデックスの変更が必要な行のみを変更します。
xml データ型の制限事項
xml データ型には、次の一般的な制限事項が適用されます。
保存する xml データ型のインスタンスは 2 GB 以内である必要があります。
sql_variant インスタンスのサブタイプとしては使用できません。
text または ntextにキャストしたり、変換することはできません。 代わりに varchar(max) または nvarchar(max) を使用します。
比較や並べ替えはできません。 したがって、xml データ型は GROUP BY ステートメント内では使用できません。
ISNULL、COALESCE、および DATALENGTH を除く組み込みのスカラー関数のパラメーターとしては使用できません。
インデックスのキー列としては使用できません。 ただし、クラスター化インデックスのデータとして使用したり、非クラスター化インデックスの作成時に INCLUDE キーワードを使用して明示的に非クラスター化インデックスに追加することはできます。
XML 要素は 128 レベルまで入れ子にできます。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示