リレーショナルデータベースにXMLを格納する根拠

Question

XML文書をデータベースに格納する必要がある理由を説明する必要があります。アップ側

：

1. 列
2. にテーブルやatrributeに個々の要素を細断する努力彼らはシステム間で移植XML
3. 内に含まれる自己されているとして、テーブル間の関係を維持する努力XMLを共有する
4. 文字通り、すべてのDBMSは、XMLをリレーショナルエンティティとしてクエリするXML操作をサポートする必要があります。下側

：RDBMSカウンターパートよりもかなり大きい

1. ネットワークペイロード。
2. クライアントアプリケーションに、使用可能なコンポーネントを細断処理す​​るように要求します。

これらの正当な理由はありますか？誰もがこれ以上考えることができますか？

Answer 1

あなたがしようとしていることに依存している決定的なプロコンが実際にはありません。

1. すべてのSQLデータベースでXML xpath（blob like '%xxx%'を超える）がサポートされているわけではありません。おそらく、XMLサポート関数を持たない古いバージョンのデータベース（つまり、Mysql 4）に悩まされているかもしれません。 Sqliteやhsqlなどのより軽いSQLデータベースもこのキャンプに入ります。
2. XMLをデータベースで検索することができますが、最適ではありません。 XMLのSQL検索では、SQLサーバーに組み込まれた検索最適化（インデックスなど）を利用できません。
3. データベースで使用するデータベースによっては、SQL Serverの検証とタイプ機能を利用できません。たとえば、OracleはXMLスキーマの検証を行うことができますが、Mysqlにはそのようなことはありません。
4. 実行可能なクエリのパフォーマンスは、標準の列クエリと比較されません。
5. データベースのサイズ。データベースにXMLを格納すると、XMLは大きくなります。あなたはそれを圧縮することができますが、それを照会するのは難しい/不可能です。
6. Normalization問題は関連する問題になる可能性があります - おそらく、ある時点でSQLを使用してXMLをクエリするとは思わないかもしれませんが、後でそのフィールドが実際に必要であると判断しました。そのフィールドをXMLから抜き出して、実際のカラムにデータを移入するだけで、必要なパフォーマンスを得ることができます。この場合、データベースに冗長な情報が含まれるようになります。

賛否両論は、実際にあなたが保管しようとしているもの、そのためのものによって異なります。

1. SQLデータベースにスティックするのが好きな理由であれば、基本的にバイナリ/構成情報が必要なだけの場合は、クエリに関する考慮事項は関係ありません。その場合、重要な問題はスペースとそれを最小限に抑える方法（つまり圧縮）に関係します。
2. XMLを定期的に検索する必要がある可能性がある場合は、クエリが遅くなり、上記の冗長性の問題が発生する可能性があります。その場合は、の長期的なデザインを非常に慎重に前に考えてください。本当にこのデータをXMLとして保存する必要がありますか？そのデータからXMLを構築する方が良いでしょうか？

Answer 2

どちらの場合もプロとメジャーがあり、使用シナリオによって異なります。

XML自体として格納することの主な欠点は、特定のデータのクイック検索を実行できないことです。検索を実行するには、すべてのXMLファイルを取得して解析する必要があります。

私たちのプロジェクトの1つでも同様の状況に遭遇しました。それを議論した後、我々は中間的なアプローチのために入りました： すべての主な情報（迅速に照会する必要のある情報）は、関連するテーブルに格納されていました。そしてXMLも保存しました。そのようなXMLを格納する代わりに、XMLをディスクに保存し、そのファイルパスをテーブルに使用しました。

Answer 3

議論コメント：

2. ここでもまた、それらの制約を強制しないことを意味個々の要素を格納していない、テーブル間の制約が保存されていない
ターゲットシステムが同じに確認した場合
3. のみポータブルスキーマ
4. はい、パフォーマンスはさまざまです。