回答:
オブジェクトデータを格納するためにXMLにシリアル化するのと同じようなことをしました。これにより、複雑なオブジェクトのデータを保持するためにテーブル、列、およびリレーションシップを配置する負担がなくなります。結果のXMLが準拠するスキーマを使用することでプロセスを支援でき、問題のオブジェクトに関するメタ情報にデータベーステーブルを使用できます。私の場合、オブジェクトレイアウトに対応するためにデータベーススキーマを拡張することは大きなタスクです。
個人的に、私はSQL ServerでXMLフィールドタイプを使用したことがなく、この機能を追加して以来、多くのデータベースプログラミングを行ってきました。データベースでXMLコンテンツをネイティブに使用するには、常にプログラム上およびパフォーマンス上のオーバーヘッドがあるように思えました。誰もが2000年代初期のある時点でXMLトレインに参加していたため、私はそれが仕掛けだと思った。「XMLは暑いので、SQL Serverに追加して、見過ごさないようにしましょう。」
私が見ることができる最高のビジネスケースは、受信したXMLベースのデータメッセージを記録することです。ここでは、構造やデータを覗きたいが、ビジネスまたは法律上の理由で元のメッセージの整合性を維持したい場合があります。XMLをテーブル構造に変換するにはオーバーヘッドが大きすぎる場合がありますが、SQL ServerでXML機能を使用すると、データの検査にかかるコストを削減して、データの使用を保証できます。
それを使用したい理由はおそらく他にもたくさんありますが、率直に言って、非常に具体的なビジネス上の理由がない限り、SQL ServerでXMLを独り占めする前に、幸福への別の道を検討すべきだと思います。より適切な場合は、varchar（max）またはテキストフィールドを使用します。
もちろん、私の意見:)
SQL ServerでXMLデータ型の使用を積極的に追求するいくつかのシナリオに遭遇しただけです。これは私の頭の一番上にあります。
99％の確率で、スキーマを設計する際にXMLフィールドはまったく必要ありません。
SQLサーバーでXMLデータ型を見た数回は、基本的にデータベースの他のフィールドと同様にクエリされるフィールドとして使用されます。大量のデータがある場合、パフォーマンスに非常に悪い影響を与える可能性があります。XMLサーバーではなくSQLサーバーと呼ばれる理由があります。:-) XMLに反するクエリは、通常の選択クエリを実行するほど高速ではありません。
ただし、XMLデータ型で完全なXMLドキュメントを保存するが、検索可能なフィールド（キー）をXMLドキュメントとは別に保存するなど、あまり照会されないXMLの保存に使用されていることがわかりました。そうすることで、情報をより高速に照会し、完全なドキュメントを表示したいポイントに到達したときにXMLドキュメントを取得できます。私は実際に戻って、多くのアプリでこれを行わなければなりませんでした。そこでは、人々はXMLデータタイプを頻繁にクエリされるフィールドとして使用しようとしましたが、クエリが遅すぎるほどデータが大きくなりました。
主に、ASMX WebサービスまたはWCFサービスに関連するログ記録の目的でXMLタイプフィールドを使用しました。要求または応答メッセージを保存できます。
ほとんどの場合、XMLを参照目的でDBに保存します-通常のビジネスアクティビティではなく（コードから5秒ごとにクエリするのではありません）。そうした場合は、通常クエリを実行するか、ほとんどの時間を使用するフィールドを決定し、それらに個別の列を作成します。そうすれば、XMLをDBに保存するときに、これらのフィールドを抽出して、対応する列に保存できます。後でそれらを取得するときに、この目的で作成した列を使用するだけでXMLドキュメントを照会する必要はありません。
データベースへの1回の呼び出しで構造化データを保存するために、クライアントサーバーアプリでXMLを広く使用しています。例として、詳細行を含む請求書を取り上げます。クライアントがビジネスオブジェクトをXMLにシリアル化し、1回の呼び出しでストアドプロシージャに渡すのは簡単です。プロシージャは、挿入または更新が必要かどうかを決定します。親請求書ID（ID列）を取得して詳細レコードに割り当てることができ、すべてサーバー側のトランザクション内で、クライアントが何度も往復する必要はありません。ヘッダーレコードを指定するために20個ほどのパラメーターは必要ありません。また、すべての請求書の行を呼び出す必要はありません。また、多くの場合、クライアントに触れることなく、スキーマを変更したり、ログ/監査を導入したりできます。