回答:
すべてのデータをリレーショナルに保存する必要はなく、リレーショナルストレージ用のXMLとして渡されたデータを処理するコードを記述するのに時間がかかります（非常に退屈です）。これは、大量のXMLデータが大量の一般的な応答をスローしているシステムから来ている場合に特に当てはまります。
別のシステムからメッセージを受信する状況をよく見ますが、その内容の約98％は気にしません。それを解析して、関心のある2％を分割し、それをリレーショナルに保存し、残りの98％のいずれかが後で必要になった場合に備えてメッセージ全体を保存します。
また、SQL Serverには、T-SQLでXMLを操作するためのいくつかのわかりやすいツールと構文が用意されているため、コンテンツを保存する場合のように、アドホッククエリの実用的な範囲を完全に超えているわけではありませんCSVの。
そして、それはあなたが実際に保存したいものがXMLである可能性を除外します（例えば、サポートとデバッグの目的のために）...
データ形式が揮発性であり、変更される可能性がある場合は、XMLとしてまとめてこの形式でデータベースに配置し、将来のデータベーススキーマの変更を回避することができます。
同じ接線上で、データが何らかの外部システムによって提供され、再び消費され、永続的な形式を提供できない場合、それがあなたのすることです。
これにより、この情報をクエリするのが難しくなりませんか？
SQL Serverは、XMLフィールドと変数を照会できます。必ずしも難しいわけではありませんが、より多くの作業が必要です。しかし、実行可能。
私の経験では、XMLデータは通常保存され、めったにクエリされませんが、通常は必要に応じて抽出されます。通常、他のシステムがリレーショナルデータからオンザフライで生成することが困難または不可能なデータのXML表現を必要とする場合です。XMLデータは、他のプロセスによって事前に入力されている場合があります。
多くの場合、XMLとリレーショナルの両方である混合データを取得します。（これの良い例は、各ドキュメントがタイトル、作成日、所有者などのようなメタデータフィールドを持つことができるドキュメントストアです。）
この時点で、次の3つのオプションから選択する必要があります。
オプション3はおそらく最もクリーンですが、最も高価で実装が最も困難です。さらに、それほど大きくないシステムで分散トランザクションが必要になるとは限りません。ネイティブXMLデータベースは通常、リレーショナルデータ（検索で使用する可能性が高い）の処理が非常に不十分であり、テクノロジはリレーショナルDBよりも全体的に成熟していないため、オプション2はあまり良くありません。
そのため、オプション1は確かに最良のソリューションではなく、おそらく最も悪いソリューションではありません。
最近、ドキュメント指向のデータストア（別名NoSql）は非常に人気があります。
http://en.wikipedia.org/wiki/Document-oriented_database
リレーショナルデータベースでドキュメント指向のスキームを使用できない理由はありません。Mongoのようなものと比較して同じ利点が得られるとは限りませんが、欠点もありません。
長い間、ドキュメント指向のストレージを使用する場合、唯一の選択肢は構造化データ（XMLなど）を大きな列に押し込むことでした。リレーショナルデータベースは、インデックス付けやマッチングなどの機能を追加してサポートしています。
これとは対照的に、データベース内で唯一のものはドキュメントです。しかし、それは別のトピックです。
編集：ドキュメント指向のコアアイデアは次のとおりです。データを引き出し、操作し、全体を押し戻します。時々、ドキュメントをクライアントに送信するときのように、単にすべてをblobとして送信し、それらに処理させたい場合があります。利点（および欠点）は柔軟性です。ドキュメントの検証と正確性は、データベースの外部で行われます。
編集編集：別のコントラスト。データベース列にJPG画像またはWord文書を保存することを想像してください。
タプルのリスト（データベーステーブル）にツリー（XML）を格納する利点は何ですか？
XPathやSPARQLなどを使用して、XMLをDBMSからクエリできない理由はありません。
ご覧のとおり、これらは2つの異なるデータ構造にすぎません。そして、それらを互いに埋め込むべきではない理由はありません。
JSONデータ型がPostgreSQLに追加された理由を調べることができます。同じ議論の多くが当てはまると思います。XML / XSDを除き、さらに多くの検証が可能です。
情報を解析するために努力する場合、そこにある必要のない非効率的なタグで効率的なストレージを詰まらせるので、それは悪い習慣だったと思います。XMLには、各行の各列に1つのタグが必要であるため、XMLが記述するデータに比べてひどいストレージオーバーヘッドがあります。比較すると、解析されてリレーショナル形式で保存されたデータの列名は一度だけ保存されます。開発者の数十行。ボックス、大したことですが、私は開発者がこれが数百万行に拡張可能であると仮定するのを見ました。これは、数十GBのデータに対して数百GBのオーバーヘッドを表し、運用上の課題を生み出します。あなたは基本的にあなた自身からの責任を放棄し、あなたが書いたがらくたをサポートしなければならない人々にプッシュしています。
それでは、運用データから離れた独自のデータベースに保存してみませんか？またはそれが意図されているように-フラットファイルで？おそらく二度と見られることはないので、運用システムのパフォーマンスを低下させないようにしましょう。XMLはデータスキーマの説明を提供するためにのみ存在することを覚えておいてください。そうしないと、システム間のストレージプロトコルの違いのために明らかになりません。それが全体のポイントであり、それについて賢いことは何もありません。一定量のデータに対して10倍のオーバーヘッドを保存するということは、あなたが物事を熟考せず、消費しているデータを賢明で効率的で高速なクエリ形式に処理することに悩まされない、ずさんな開発者だというだけです。運用サポートに力を注ぐのをやめ、その後のデータ処理の改善方法について考えてください。veがそれを受け取ったのは私の電話です。目的を果たしているため、データを受信した後、XMLとして保存するための防御策はありません。