リレーショナルデータベースにxmlを保存する利点は何ですか？
今日、AdventureWorksデータベースを探し回っていましたが、多くのテーブル（HumanResources.JobCandidateおよびSales.Individualの例）xmlデータを格納する列があります。
私が知っておくべきことは、基本的にデータベーステーブルの行に相当するデータを別のテーブルの列に格納することの利点は何ですか？これは、この情報を照会することを難しくしませんか？それとも、データを照会する必要はなく、格納するだけでよいという想定ですか？
すべてのデータをリレーショナルに格納する必要があるわけではなく、リレーショナルストレージのXMLとして渡されたデータを処理するコードを記述するのは時間がかかります（そして非常に退屈です）。これは、大量の一般的な応答をスローしているシステムから大量のXMLデータが送信される場合に特に当てはまります。
別のシステムからメッセージを受信する状況をよく見ましたが、メッセージの内容の98％は気にしていません。したがって、それを解析して、関心のある2％を分割し、それを関係的に格納し、後で残りの98％が必要になった場合に備えてメッセージ全体を格納します。
また、SQL Serverは、T-SQLでXMLを操作するためのOKっぽいツールと構文を提供するので、コンテンツを格納している場合のように、アドホッククエリの実際の範囲を完全に超えているわけではありません。 CSVの。
そして、それはあなたが実際に保存したいものがXMLである可能性を排除します（例えば、サポートとデバッグのために）...
データ形式が揮発性であり、変更の可能性がある場合は、それをXMLとしてまとめ、この形式でデータベースに配置することで、将来のデータベーススキーマの変更を回避できます。
同じ接線で、データが外部システムから提供されて再び使用され、恒久的な形式を提供できない場合は、そうします。
これは、この情報を照会するのを難しくしませんか？
SQL Serverは、XMLフィールドと変数をクエリできます。必ずしも難しいとは限りませんが、より多くの作業が必要です。しかし、実行可能です。
私の経験では、XMLデータは通常保存され、照会されることはほとんどありませんが、必要に応じて抽出されることがよくあります。通常、他のシステムがリレーショナルデータからオンザフライで生成することが困難または不可能である可能性があるデータのXML表現が必要な場合です。 XMLデータは、他のプロセスによって事前に入力されている場合があります。
データをblobのバイナリストリームに格納することを想像できる場合、データをxml形式でblobに格納することを想像できます。
もちろん、想像者の想像力には多くのものが残されています。
たとえば、電子カルテ：
おそらくASCII HL7 V2.xをデータベースのフィールドに格納します。おそらく、HL7 V3.0をデータベースのフィールドに格納しがちです。
したがって、利点は利便性です。
私は現在、これを行うプロジェクトに取り組んでいます。複数の処理が必要なデータがあり、リレーショナルに保存されています。ただし、処理はJavaで行われるため、そこでXMLを処理する方が簡単です。したがって、リレーショナルデータを1回だけパスして、XMLとしてテーブルに格納します。次に、そのデータをJavaでデータを毎回取得するのではなく、1つの非結合クエリで処理し、同じデータを何度も繰り返し処理することができます。これは、はるかに単純で効率的です。 。
XMLを格納する良い例は、UIの状態をデータベースに永続化したい場合です。すべてのアプリケーションビューの状態はシリアル化され、データベースに保存されます。XMLをクエリする必要はありません。 UIの状態とは、つまり、ビューの並べ替え順序、ウィンドウのサイズなどです。
多くの場合、XMLとリレーショナルの両方である混合データを取得します。 （これの良い例は、各ドキュメントがタイトル、作成日、所有者などのメタデータフィールドを持つことができるドキュメントストアです。）
この時点で、3つのオプションから選択する必要があります。
- すべてをリレーショナルDBに保存します。
- すべてをネイティブXML DBに保存します。
- データを2つの別個のDBに保存します。XMLはネイティブXMLで、メタデータはリレーショナルです。
オプション3はおそらく最もクリーンですが、最も高価で実装が最も困難です。さらに、それほど大きくないシステムで分散トランザクションを必ずしも必要とするわけではありません。オプション2は、ネイティブXMLデータベースは通常、リレーショナルデータ（検索で使用する可能性が高い）の処理が非常に貧弱であり、テクノロジーはリレーショナルDBよりも全体的に成熟していないため、あまり良くありません。
したがって、オプション1は確かに最良の解決策ではなく、おそらく最も悪い解決策となります。
ドキュメント指向のデータストア（別名NoSql）は最近非常に人気があります。
http://en.wikipedia.org/wiki/Document-oriented_database
リレーショナルデータベースでドキュメント指向のスキームを使用できない理由はありません。 Mongoのようなものと比較して、同じ利点がすべて得られるとは限りませんが、欠点もありません。
長い間、ドキュメント指向のストレージを使用したい場合、唯一の選択肢は構造化データ（XMLなど）を大きな列に押し込むことでした。リレーショナルデータベースには、それをサポートするためのインデックス作成やマッチングなどの機能が追加されています。
データベースとonlyがドキュメントであるMongoとは対照的です。しかし、それは別のトピックです。
編集：ドキュメント指向の核となるアイデアは、データを引き出して操作し、全体を元に戻すことです。ドキュメントをクライアントに送信するときのように、全体をBLOBとして送信し、それらに処理させたい場合があります。利点（および欠点）は柔軟性です。文書の検証と正確性はデータベースの外部で行われます。
編集編集：別のコントラスト。データベースの列にJPG画像またはWordドキュメントを保存することを想像してください。
私の経験では、データベースでのXMLの使用は、データのソースがそれを格納する方法であるか、既存のデータベースにXMLを追加して、サポートするために多くのデータベースプログラミングを必要としない方法で機能を拡張するためです。
新しいデータを頻繁に検索する場合は、代わりにXMLをコンポーネントパーツに分割するのが理にかなっています。そうでない場合は、あまり変更されないデータを保存するのに便利な方法です。
これが役に立てば幸い、ジェフ
タプルのリスト（データベーステーブル）にツリー（XML）を格納する利点は何ですか？
XMLを使用して、DBMSからXMLをクエリできないようにする必要はありません。 XPathまたはSPARQL。
私が見ると、それらは単に2つの異なるデータ構造です。そして、それらが互いに埋め込まれるべきでない理由はありません。
JSONデータ型がPostgreSQLに追加された理由を調べることができます。同じ議論の多くが当てはまると思います。 XML/XSDを使用する場合を除いて、さらに多くの検証が可能です。