データストレージとしてのXMLの使用
私はXML形式と次の引用について考えていました：
「XMLはデータベースではありません。データベースであることを意図したものではありません。データベースになることは決してありません。リレーショナルデータベースは、20年以上の実装経験を持つ実績のあるテクノロジーです。彼らは固体、安定した、有用な製品です。彼らは消えません。 XMLは、異なるデータベース間、またはデータベースと他のプログラム間でデータを移動するための非常に便利なテクノロジーです。ただし、それ自体はデータベースではありません。 「- 効果的なXML：XMLを改善するための50の方法 by Elliotte Rusty Harold （230ページ、パート4、アイテム41、2番目の段落）
これは、XMLがデータストレージに使用されるべきではなく、プログラム間の相互運用性にのみ使用されるべきであることを本当に強調しているようです。
個人的に、私は同意しません。NETのapp.configプログラムの設定を保存するために使用されるファイルは、XMLファイル内のデータストレージの例です。ただし、構成などではなくデータベースの場合、XMLは使用しないでください。
私のポイントを発展させるために、私は2つの例を使用します：
A）すべてが1レベルにあるフィールドを持つ顧客に関するデータ。つまり、子のない1人の顧客にすべて関連するフィールドがいくつかあります。
B）ネストされたフィールドとプロパティが意味をなすアプリケーションの構成に関するデータ
それで私の質問は、これはまだ有効なステートメントであり、XMLを使用してデータを格納することは今や受け入れられるのですか？
編集：私は彼の入力/余分なコンテキストを求めるためにその引用の著者に電子メールを送りました。
この引用は、XMLをストレージ形式として一般的に使用すること（これは要件に応じて問題ありません）ではなく、database-typeストレージ用です。
人々がデータベースについて話すとき、それらは通常ギガバイトまたはテラバイトの範囲で、巨大な大量のデータを保存するストレージシステムを意味します。データベースは、それを格納するサーバーで利用可能なRAMの量よりもはるかに大きくなる可能性があります。誰も一度にデータベース内のすべてのデータを必要としないため、データベースを最適化して、データの選択したサブセットをすばやく取得する必要があります。これがSELECTステートメントの目的であり、リレーショナルデータベースとNoSQLソリューションが最適化しますそのようなサブセットをすばやく取得するための内部ストレージ形式。
ただし、XMLはこれらの要件に実際には適合しません。ネストされたタグ構造のため、少なくとも一致するまで、ドキュメントツリー全体をウォークしないと、ファイル内の特定の値が（ファイルへのバイトオフセットに関して）保存されている場所を特定することはできません。リレーショナルデータベースにはインデックスがあり、プリミティブなバイナリ検索の実装でも、インデックスで値を検索するのは1回の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％の範囲になることも珍しくありません）。 、一般的なリレーショナルDBストレージスキームでは、テーブルメタデータのオーバーヘッドが一定で、行ごとにごくわずかです。リレーショナルデータベースのオーバーヘッドのほとんどは、固定された列幅に起因します。テラバイトのデータがある場合、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がデータベースになることも、それを置き換えることも決してありません。
XMLは主にallows for the creation of customized tags for individual information fields.ただし、これを使用してリレーショナル集中型データ管理を実現することはできません。
私の質問は、これはまだ有効なステートメントであり、XMLを使用してデータを格納することは今や受け入れられるかということです。
.NET構成ファイルの例で、あなたのポイントがわかります。ただし、他のファイル形式を使用することもできます。実際、昔は、そのような設定はINIファイルと呼ばれる通常のテキストファイルに保存されていました。
あなたが灰色で示したステートメントは、データベースをソフトウェアシステムとして定義する場合に有効かつ正しいことがわかります。
XML-Definition でのXMLの定義は、「（XML）は人間が読める形式と機械が読める形式の両方でドキュメントをエンコードするための一連のルールを定義するマークアップ言語である」と述べています。
この定義は、データを管理するメカニズムではなく、可読性と言語に焦点を当てています。
RDBMSと比較して、XMLはXMLファイルの行をランダムに挿入および削除する手段を提供しません。たとえば、1000000行があり、シングルユーザー環境でもランダムに行を削除したい場合、XMLベースのファイルはデータベースには適していません。また、XMLはデータをロックするためのネイティブのメカニズムを提供しません。実際、XMLはソフトウェアではないため、データベーストランザクションが共有環境で確実に処理されることを保証するすべてのACID（原子性、一貫性、分離、耐久性）のプロパティは、開発者が構築する必要があります（耐久性を除く）。 XMLには、さまざまなサーバーはもちろんのこと、XMLファイル全体のデータ整合性を処理するための堅牢な仕様がありません（たとえば、顧客xmlファイルと注文xmlファイル-整合性を適用するFKはありません）。
上記はXMLに欠けているものの列挙ではなく、代わりに、XMLがデータベースソフトウェアではないというステートメントの簡単な正当化として機能します。
そもそもなぜデータの保存に実際にXMLを使用したいのですか？つまり、それはlanguageですから...
これは柔軟で理解しやすい形式であると主張することもできますが、これはファイルを手動で編集する必要がある場合にのみ適用されます。実際にデータベースと共通のインターフェイス（要件YおよびZを満たすデータXをフェッチ、データXを保存/更新）で操作すると、これらの利点は無効になります。
短い答え：場合によります。
長い答え：私の観点からは、これは保存するデータの量に大きく依存します。例えば。実行時にアプリケーションにいくつかのオブジェクトがあり、ツールの実行後にそれらを保存する場合は、XMLファイルで十分です。ただし、Webショップに5000人の顧客がいて、さらに多くの注文がある場合は、データベースがより適切なデータストレージになります。
さらに、app.configのようなファイルではなくデータベースに設定を保存することはほとんどの場合あまり役に立ちませんが、この例では引用が間違っていることを証明しているとは思いません。
XMLは、構成設定に最適です。 XMLファイルは、IDEで簡単に解析/ハイライトできるだけでなく、プログラマー以外でも簡単に編集できます。設計者やコンテンツ管理者がメンテナンスタスクを実行しているWeb開発シナリオでは、これらが非常に役立つことがわかりました。
通常、XMLは重要なアプリケーションのプライマリデータソースとして使用しないでください。シリアライゼーション/デシリアライゼーションのオーバーヘッドだけでも、別のソリューションを要求します。
リレーショナルデータベースではないことに同意します。著者は引用の中で、それを1つとして使用しないように単に言っていると思います。
あなたはそれを必要とするかもしれないし必要としないかもしれませんがデータに対して多くのクエリを実行する必要がなく、データを保存して、いくつかの限られたクエリ基準に基づいて後でフェッチするだけの場合は、リレーショナルデータベースではなくXML DOCUMENTのストレージと取得が必要です。
後で全体を取得するために、データを含むドキュメントを格納するだけで済むアプリケーションはたくさんあります。これが事実である場合、SQLベースのスキーマを作成し、XMLを解析し、それをデータベースにシリアル化して、後で逆の処理を行うだけでは意味がありません。これを行うには、潜在的に多くのコードオーバーヘッドが伴います。あなたがそれを正しく行えば、より少ないです。
HibernateなどのORMツールやApache Axisなどのツールを使用して、単純なCRU操作を処理するだけのサービスを構築するために必要なコードを事実上すべて自動生成できます。もちろん、それを認証でラップする必要があり、ユーザー、アクセスレベルなどに基づいてデータを分離する必要があるかもしれません。特定のユーザーがSOAPサービスなど。
この意味で、あなたは何よりもコンテンツ管理のようなことをしています。
databaseという用語は、生データのみ、またはデータベース管理システムのいずれかを指します。この定義は、議論全体に大きな違いをもたらします。
RDBMS定義を使用する場合、XMLはその意味でほとんど機能しません。 ACIDの保証に関しては、ほとんど何も得られません（それらを実現するには、独自のコードを記述する必要があります）。それらが必要な場合（そしてほとんどのトランザクションシステムで必要な場合）、すでに大きな問題に直面しています。私は、RDBMSで当たり前と見なされている何百もの機能のリストを提供できます。いくつかの基本的なものを挙げれば、セキュリティモデル、レプリケーション、バックアップを考えてください。
上記の意味では、いいえ、XMLはデータベースではないため、XMLをデータベースとして使用しないでください。
「生データ」の定義を使用すると、XMLの方がはるかに優れていますが、それでもそれほど優れていません。他の人が指摘したように、それは一般に非常に冗長であり、通常はバイナリエンコーディングが欠落しており、タグが重複しています。これらは、XMLを人間が読めるようにするために作成されたトレードオフです。基本的に、効率はこの要件の敵です。また、XMLは、レコードを継続的に挿入する最も単純な状況にも特に適していません。 XMLファイルを有効にする場合は、単一の終了タグが必要です。つまり、レコードを追加すると、最後にタグをシフトアップする必要があります。これはかなりコストがかかります（そのタグの開始位置をどのように知るのですか？複数の "テーブル"がある場合、ファイル全体を上に移動するだけですか？）、それを回避したい場合は、同様のアプローチを再発明します多くのデータベース-テーブルを複数のファイルに分散し、必要に応じてそれらのファイルを動的に拡張します。
XMLが適切である状況があります-構成ファイルは典型的な例であり、人間の読みやすさが優れた機能であるため、構成ファイルはその良い例です。設定ファイル専用のデータベースを用意するのはやり過ぎかもしれません。
一方、データベースは、数千（または数百万/数十億）のレコードがあり、多数のユーザーが同時にそれらを更新する場合に優れています。つまり、XMLはデータベースではないので、XMLのように使用すべきではありません。あなたの例は、最初からDBを必要としなかった状況の1つであり、XMLの方が適しています。
私がそれを見る方法はこれです：XMLをDBとして（たとえば、トランザクションシステムのバッキングストアとして）使用する場合、RDBMSを再発明して書き直すことになります。それはあなたの時間とエネルギーを使う本当に貧弱な方法です。これもその引用が言っていたことだと思います。