データストレージとしてのXMLの使用[終了]

私はXML形式と次の引用について考えていました。

「XMLはデータベースではありません。データベースになることを意図したものではありませんでした。データベースになることはありません。リレーショナルデータベースは、20年以上の実装経験を持つ実績のあるテクノロジーです。彼らは、固体、安定した、有用な製品です。彼らは去りません。XMLは、異なるデータベース間またはデータベースと他のプログラム間でデータを移動するための非常に便利なテクノロジーです。ただし、それ自体はデータベースではありません。いずれかのようにそれを使用しないでください「 - 。効果的なXML：50の具体的な方法をあなたのXMLを向上させることではElliotte Rusty Harold著（230ページ、パート4、項目41、第二段落）

これは、XMLをデータストレージに使用すべきではなく、プログラム間の相互運用性にのみ使用すべきであることを本当に強調しているようです。

個人的にはapp.config、プログラムの設定を保存するために使用される.NETのファイルは、XMLファイルのデータストレージの例です。ただし、構成などではなくデータベースにはXMLを使用しないでください。

ポイントを開発するために、2つの例を使用します
。A）すべてが1レベルのフィールドを持つ顧客に関するデータ。つまり、子を持たない1人の顧客にすべて関連するいくつかのフィールド
があります。とプロパティは非常に理にかなっています

だから私の質問は、これはまだ有効なステートメントであり、XMLを使用してデータを保存することは現在受け入れられますか？

編集：私は彼の入力/追加のコンテキストを求めるためにその引用の著者にメールを送りました。

この引用は、一般にストレージ形式としてXMLを使用することに関するものではなく（要件に応じて適切です）、データベースタイプのストレージ用です。

人は、データベース保存し、それらの通常平均ストレージ・システムについて話すとき、巨大な、多くの場合、ギガバイトまたはテラバイトの範囲内で、データの量を。データベースは、それを保存するサーバーで使用可能なRAMの容量よりもはるかに大きい可能性があります。誰もデータベースのすべてのデータを一度に必要とすることはないため、データベースはデータの選択的なサブセットの高速検索のために最適化する必要があります：これはSELECTステートメントの目的であり、リレーショナルデータベースおよびNoSQLソリューションは内部ストレージフォーマットを最適化して高速化しますそのようなサブセットの取得。

ただし、XMLはこれらの要件に実際には適合しません。タグ構造がネストされているため、少なくとも一致するまでドキュメントツリー全体をたどることなく、ファイル内の特定の値が（ファイルへのバイトオフセットに関して）格納されている場所を特定することはできません。リレーショナルデータベースにはインデックスがあり、インデックス内の値の検索は、プリミティブバイナリ検索の実装であっても、単一のO（log n）ルックアップであり、実際の値に到達するのはファイルシーク（たとえば、fseek(data_file_handle, row_index * row_size)）、これはO（1）です。XMLファイルで最も効率的な方法は、ドキュメントに対してSAXパーサーを実行し、実際のデータに到達する前に非常に多くの読み取りとシークを実行することです。インデックスを使用しない限り、これをO（n）より良くすることはほとんどできませんが、挿入するたびにインデックス全体を再構築する必要があります（以下を参照）。

挿入はさらに悪い。リレーショナルデータベースは行の順序を保証しません。つまり、新しい行を追加したり、「削除済み」とマークされた行を上書きしたりできます。これは非常に高速です。DBは書き込み可能な場所のプールを保持できます。プールからエントリを取得するのは、プールが空でない限りO（1）です。最悪の場合、プールは空であり、新しいページを作成する必要がありますが、これもO（1）です。対照的に、XMLベースのデータベースでは、スペースを確保するためにすべてを挿入ポイントの後に移動する必要があります。これはO（n）です。インデックスが機能するようになると、事態はさらに興味深いものになります。典型的なリレーショナルデータベースインデックスは、O（log n）などの比較的低い複雑さで更新できます。ただし、XMLファイルのインデックスを作成する場合、挿入するたびにドキュメント内のすべての値のディスク上の場所が変更される可能性があるため、インデックス全体を再構築します。これは更新にも当てはまります。たとえば、要素のテキストコンテンツを更新するとサイズが変わる可能性があるため、連続するXMLをシフトする必要があるためです。インデックス付けされていない列を更新する場合、リレーショナルデータベースはインデックスにまったく触れる必要はありません。XMLデータベースは、更新されたXMLノードのサイズを変更する更新ごとにインデックス全体を再構築する必要があります。

これらは最も重要な欠点ですが、他にもあります。XMLは非常に冗長で、サーバー間通信に適しています。これは、安全性が向上するためです（受信サーバーはXMLに対してあらゆる種類の整合性チェックを実行でき、転送で何か問題が発生した場合、ドキュメントは検証されません）。ただし、大容量記憶装置の場合、これは致命的です。XMLデータのオーバーヘッドが100％以上になることは珍しくありません（SOAPメッセージのようなものでオーバーヘッド率が1000％の範囲になることは珍しくありません）。スキームには、テーブルメタデータのオーバーヘッドが一定しているだけでなく、行ごとに小さなビットがあります。リレーショナルデータベースのオーバーヘッドのほとんどは、固定列幅に起因します。テラバイトのデータがある場合、500％のオーバーヘッドは、多くの理由で単に許容できません。

XMLは、データの保存には不十分です。まず、非常に冗長です。XMLファイルに保存されたデータは、合理的なデータベースシステムに保存された同じデータよりもはるかに多くのディスク容量を必要とします。XMLレコードでは、特定のフィールドの名前が、データの文字列表現とともに2回保存されます。したがって、たとえば、「foobar」というフィールドに単一のインテガーを格納するには、この19バイトの文字列になります。

<foobar>42</foobar>

一方、実際のデータベースはこれを単一の整数値として保存し、4バイトを使用します。データベースが小さい場合、それはあまり意味がありませんが、10,000件のレコードがある場合、それは問題です。

次に、ファイルが読み取られるたびに、XMLをテキストから解析する必要があります。上記のフィールドの場合、実際のデータベースは、フィールド "foobar"が格納されていることがわかっているオフセットからバイナリデータをメモリに読み込みます。ファイルがXMLとして格納されている場合、フィールド "foobar"を読み取って、 、それがどのフィールドであるかを判断し、文字列「42」を解析してバイナリ42に変換します。

したがって、XMLを使用するとパフォーマンスが大幅に低下します。XMLの利点は、多少人間が読めることであり、完全に独立したシステム間でデータを簡単に転送できることです。これらの利点はどちらもローカルデータベースには当てはまりません。

1つの例外は構成ファイルです。構成ファイルは一般に小さく、通常は人間が編集できる必要があります。

XMLデータベースは、合理的なSQLシステムよりも絶対的に大きく、遅くなります。人間の可読性や相互運用性のバランスをとる利点を見つけられない限り、それをデータストレージに使用しても意味がありません。

XMLはコンテキストに応じて実行可能です。データがかなり静的であり、あまり変化しない場合（サンプルデータなど）、はいXMLは適切な使用法です。

構成設定、サンプルデータ（数百万行であるが、めったに変更されない場合でも）は、すべてXMLの優れた用途です。

ハードディスクの読み取り/書き込みは高価で、Oracle / Sqlスタックのデータにアクセスするよりもはるかに高くなります。

これは、XMLをデータストレージに使用すべきではなく、プログラム間の相互運用性にのみ使用すべきであることを本当に強調しているようです。

あなたの前提には欠陥があります。

あなたが引用した段落は、XMLがデータベースの代わりではなく、データストレージに使用されるべきではないと言っています。

設定ファイルはデータベースと同じものではないことは明らかであるため、異なるテクノロジーを使用できます（使用すべきですか？）。

私が間違っている場合は修正してください。ただし、データベースよりもマークアップ言語の方が経験があるようです。データベースの経験が少しあれば、2つの異なるテクノロジーがどちらのドメインに適しているかがわかるでしょう。

これは本当に主観的です。その引用は、誰かの意見のように、人です。

正直に言って、XMLはRDMSよりも優れた複数の利点を持っているため、データベースの実行可能な代替手段であると思います。

見てくださいdasBlogとBlogEngineを。これらのアプリケーションは両方とも、デフォルトとしてストレージにxmlを使用します。

そうは言った。これはRDMSではありません。データのボラティリティが高い（更新、挿入、または削除が多い）場合、または高可用性が必要な場合は、データベースを使用してください。XMLは、構成データや低揮発性データなどの小さなものを保存するのに適しています。

私の質問は、これはまだ有効なステートメントであり、XMLを使用してデータを保存することは現在受け入れ可能ですか？

.NET構成ファイルに関する例であなたのポイントを見ます。ただし、他のファイル形式も使用できます。実際、昔は、このような設定はINIファイルと呼ばれる通常のテキストファイルに保存されていました。

データベースをソフトウェアシステムとして定義すると、灰色で表示されたステートメントが有効で正しいことがわかります。

XML-DefinitionでのXMLの定義 は、「（XML）は、人間が読み取れる形式と機械が読み取れる形式でドキュメントをエンコードするための一連のルールを定義するマークアップ言語です」と述べています。

この定義は、データを管理するメカニズムではなく、読みやすさと言語に焦点を当てています。

RDBMSと比較して、XMLはXMLファイルの行をランダムに挿入および削除する手段を提供しません。たとえば、1000000行があり、単一ユーザー環境でも行をランダムに削除したい場合、XMLベースのファイルはデータベースには適していません。また、XMLはデータをロックするためのネイティブメカニズムを提供しません。実際、XMLはソフトウェアではないため、データベーストランザクションが共有環境で確実に処理されることを保証するすべてのACID（原子性、一貫性、分離、耐久性）プロパティは、（耐久性を除いて）開発者に任されています。XMLには、XMLファイル間でデータの整合性を処理するための堅牢な仕様がありません。異なるサーバーはもちろんです（たとえば、顧客xmlファイルと注文xmlファイル-整合性を強制するFKはありません）。

上記はXMLに欠けているものの列挙ではなく、XMLがデータベースソフトウェアではないというステートメントの迅速な正当化として役立つ可能性があります。

XMLがデータベースになることも、それを置き換えることもありませんでした。

XMLは主にWebドキュメント用に定義されていますが、XMLをallows for the creation of customized tags for individual information fields.使用してリレーショナルな集中データ管理を実現することはできません。

そもそもデータを保存するために実際にXMLを使用したいのはなぜですか？結局のところ、それは言語です...

柔軟で理解しやすい形式であると主張することもできますが、これはファイルを手動で編集する必要がある場合にのみ適用されます。実際に共通のインターフェイス（要件YおよびZを満たすデータXを取得し、データXを保存/更新する）でデータベースと対話する場合、これらの利点は無効になります。

短い答え：状況によります。

長い答え：私の観点から、これは保存したいデータの量に強く依存します。たとえば、実行時にアプリケーションにいくつかのオブジェクトがあり、ツールの実行後にそれらを保存する場合、XMLファイルはまったく問題ありません。ただし、Webショップに5000人の顧客がいて、さらに多くの注文がある場合は、データベースがより適切なデータストレージになります。

また、設定をapp.configなどのファイルではなくデータベースに保存することは、ほとんどの場合あまり有用ではないと思いますが、この例が引用を間違っているとは思わないと思います。

XMLは、構成設定の優れた選択肢です。IDEでXMLファイルを解析/強調表示するのは簡単であるだけでなく、プログラマーでない人でもXMLファイルを非常に簡単に編集できます。デザイナーやコンテンツマネージャーがメンテナンスタスクを実行しているWeb開発シナリオでは、非常に便利です。

通常、XMLは重要なアプリケーションのプライマリデータソースとして使用しないでください。シリアル化/逆シリアル化のオーバーヘッドだけで、別のソリューションが必要になります。

データベースという用語は、生データのみを指すことも、データベース管理システムを指すこともあります。この定義は、議論全体に大きな違いをもたらします。

RDBMS定義を使用する場合、XMLはその意味ではほとんどありません。ACIDの保証に関してはほとんど得られません（これらを実現するには、独自のコードを記述する必要があります）。それらが必要な場合（およびほとんどのトランザクションシステムが必要とする場合）、すでに大きな問題に直面しています。RDBMSで当たり前のことと考えられている何百もの機能のリストを提供することができます。いくつかの基本的なものを挙げると、セキュリティモデル、レプリケーション、バックアップを考えてください。

上記の意味で、いや、XMLはデータベースではないので、XMLをデータベースとして使用すべきではありません。

「生データ」の定義を使用すると、XMLの方がはるかに優れていますが、それでもそれほど優れていません。他の人が指摘しているように、それは一般に非常に冗長で、通常はバイナリエンコーディングがなく、タグが重複しているなどです。これらはXMLが人間が読めるようにするためのトレードオフです-基本的に、効率はこの要件の敵です。また、XMLは、レコードを連続して挿入する最も単純な状況にも特に適していません。XMLファイルを有効にするには、単一の終了タグが必要です。つまり、レコードを追加すると、最後にタグをシフトアップする必要があります。これは非常に高価です（そのタグがどこから始まるのかを知るにはどうすればよいですか？複数の「テーブル」がある場合、ファイル全体を上に移動するだけですか？）、それを回避したい場合は、

XMLが適切な状況があります。設定ファイルは典型的な例であり、人間が読みやすいのは優れた機能であるため、設定ファイルは優れた例です。構成ファイル専用のデータベースを持つのはやり過ぎかもしれません。

一方、データベースは、数千（または数百万/数十億）のレコードがあり、多数のユーザーがそれらを同時に更新している場合に優れています。そのため、XMLはデータベースではないため、XMLをデータベースのように使用しないでください。あなたの例は、そもそもDBを必要としない状況の1つであり、XMLがより適しています。

私が見る方法はこれです： XMLをDBとして（たとえば、トランザクションシステムのバッキングストアとして）使用すると、RDBMSの再発明と書き換えになります。それはあなたの時間とエネルギーを費やす本当に悪い方法です。これもその引用が言っていたものだと思います。

リレーショナルデータベースではないことに同意します。著者は引用文の中でそれを一つとして使わないように言っているだけだと思います。

あなたはそれを必要とするかもしれないし、必要としないかもしれないが、と言った データに対してあまり多くのクエリを実行する必要がなく、データを保存してから、限られたクエリ条件に基づいて後でフェッチする場合は、リレーショナルデータベースではなく、XMLドキュメントの保存と取得が必要です。

後で検索するために、データを含むドキュメントを保存するだけで十分なアプリケーションがたくさんあります。この場合、SQLベースのスキーマを作成し、XMLを解析してから、データベースにシリアル化して、後で逆に行うだけでは役に立ちません。それを行うには潜在的に多くのコードオーバーヘッドがあります。あなたがそれを正しくすればもっと少ないです。

HibernateなどのORMツールやApache Axisなどのツールを使用して、単純なCRU操作を処理するだけのサービスを構築するために必要なコードを実質的に自動生成できます。もちろん、認証でそれをラップする必要があり、場合によっては、ユーザー、アクセスレベルなどに基づいてデータを分離することもできます。特定のユーザーがSOAPサービスを介して実行できる操作を制限することもできます。例。

この意味で、あなたは他の何よりもコンテンツ管理に似ています。