コンピュータのデータの蓄積方法についての質問、ご意見のお伺いです。

私自身はXMLを殆ど使ったことが無いですが、この場合利点はあまりないですね。

少なくともRDBの代わりは辛いと思います。

テーブル一つや階層構造などの単純構造で、データ量がさほど多くないのであれば

同じエンジン内で処理できる分、XMLデータベースの方が速いでしょう。

メタデータの扱いに長けているという点もあるかもしれません。

例えば個人参加型のWebアルバムや、ファイル共有システムなんかは効果が期待できそうです

http://www.cybertech.co.jp/xml/faq/xmldb_1/xml_1.php

一方、テーブル間で共通の値を持たせるとなると、独自のエンジンを持ってるRDBの方が速いでしょう。

とくに結合Viewなどは内部に独自エンジンを持っているRDBの方がパフォーマンスが多いです。

また、レコード数が多い場合、インデックスを張れないXMLはパフォーマンスが大きく低下します。

あと、これは考えが古いのかもしれませんが

とくにインターネットを利用したサービスの場合、データをためておく箱と、公開するインターフェイスは

別環境で動かしたいと考えています。

箱とインターフェイスが同一環境で動いていると、ちょっとした穴を突かれて機密情報が漏洩してしまいますが

別々ならば。インターフェイスが完全に乗っ取られ、さらにDBのユーザ、PWが漏れない限り

そうそう情報漏洩にはならない、と思っているからです。

確かにRDBは便利ですがいくつかの弱点があります

1.全文検索系の用途には適しません

　使用するとなるとLOB型にせざる得ないと思いますが

　そうなるとあまりインデックスが意味を持たなくなり、

　別に無理にRDBにする必要性がなくなってしまいます

　# 容量計算も面倒ですし

2.項目は基本的に固定であり、簡単に増減できない

　数個のデータしかある項目を使用することがないという場合でも

　全てのデータに項目を追加しなければならない

3.階層構造やグラフを表現しにくい

　単純な階層構造の場合はキーを余分に付け加えれば表現は可能ですが、

　グラフ構造になると途端に面倒になる

　# 例えばA社員がB課とC課を兼任するという組織図をRDBでは表現しにくい

無論、XMLにも弱点はあります

・RDBみたいな高速な更新や検索は(今の所)できません

・SQLのようなXMLにアクセスする統一的な仕様は(今の所)ありません

　# 検索だけはXPathは使えますが

XMLの利点は柔軟なデータ構造を実現できることです

全てのデータをRDBのみで扱うこともXMLのみで扱うことは馬鹿げています

この世に色々プログラム言語が存在するように

データベースも色々あってもいいじゃないでしょうか？

1. RDBだとスキーマががちがちに固まってしまいますが、

XMLだと柔軟に変えることができます。

http://www.xmldb.jp/db_contents/xpriori/original/rdb_xmldb.html

RDBだとどうしても２次元の表になってしまいがちで、DBになれてないユーザーですと

なかなか直感的には扱えないというのが主なメリットのようです。

まぁあとは、最近流行のXMLデータをそのまんま格納できて(検索できて)便利じゃないか。

といったこともあると思います。

ただ、最近のRDBMSにはXML対応が(不完全なりとも)行われてきているので

そこまで気にする必要なないんじゃないかなと思います。

"XML対応"の形はぜんぜん違えども、

http://japan.zdnet.com/news/db/story/0,2000056180,20135508,00.ht...

http://dev.mysql.com/doc/refman/5.1/ja/xml-functions.html

各プロダクトとも対応してきていますので、XML用の何かを用意してというよりは、

そのまま使えるものは使う感じでいいんじゃないかなと個人的には思いますが。

保存するべきデータ数（カラム数）が一定ではない場合、DBにそのまま登録することはできません。

やるとしたら以下の手があります。

１．保存できるデータ数に上限を持つ

２．データをCSVにやバイナリに変換してDBに保存する

しかし、開発途中でデータの順番が入れ替わったり、数が増えたりした場合、

読み書きのメソッドを変更しなくてはならなくてとても面倒です。

「あれ、２番目のデータはなんだっけ？」とか悩みます。

構造体のメンテしたりも面倒です。

そこで、XPATH書式が使えるXMLが普及してきました。

昨今は、DBのほうも変化してきて、XML型のデータを保存することができるようになったり、XML DBなんてものも出てきています。

DBに無理矢理なデータ構造を持たず、場合によってはXML型でDBに登録するというやり方はシンプルだと思います。

新聞記事のデータのような不定形のものにセマンティックな構造をつけたまま取り扱う場合、XMLで格納する必要があります。

たとえば、記事内の様々な部分にキーワードやリンク、人名情報、読み仮名情報などが含まれる場合、これらを検索可能な形でRDBに納めるのはかなり面倒です。

たとえば、「森」という人名が含まれる新聞記事を検索する、というような場面を考えると、データベースにXMLでタグ付けされた記事が格納されていて、そのデータベースがXML対応の検索ができる（人名を表すエレメントの中に森という文字が含まれている記事、という設定で該当データを検索できる）必要があります。

個人的には、XMLで取り扱った方が有利なのは記事や論文、電子マニュアルのような本質的に非定型であるものだと思います。（ブログのデータでも使われますね。）

XMLの前身規格であるSGMLはアメリカ国防総省が納品メーカーから受け取る電子マニュアルを作成するための文書形式として発達した、という話もあるくらいですから、XMLもこのような用途で使用されることがかなりあります。

しかしながら「XMLスキーマ（固有名詞の方）」ではこのような不定型データを取り扱うような用途には向いていません。

不定形データはDTD（別種のXMLのスキーマ）でデータ定義が提供されていることが多いようです。DTDはSGMLから引き継いだものを改変したもので、データ型の指定やネームスペースの仕様等の能力でXMLスキーマに劣っています。

（さらに別種のスキーマであるRelax NGが複雑な構造の定義に向いていると聞いているのですが、あまり見たことがありません。）

なおXMLにおけるSQL的検索方法としてはXQueryがありますが、現在はあまり一般的でないかもしれません。

別の例

以下のような部署テーブルがある

部署名

A部

B部

C部

以下のような人員テーブルがある

社員番号 名前

0001 Aさん

0002 Bさん

0003 Cさん

部署テーブルに人員リストというXMLカラムを追加

部署名　人員リスト

人員リストはXML型で以下のような内容にする

<root name="A部">

<people>

<person>0001</person>

<person>0002</person>

<person>0003</person>

</people>

</root>

ということが出来ます

正規化が必要なく、構造を変更したくなったときにはスキーマの変更がXSLTなどで簡単にできること、構造のバージョン管理もXSLTで管理できるなど。

他、XMLをデータとして使えることにより、別のフォーマットに変換して出力することなどが容易であることなどではないかと思います。

データ構造の柔軟性という観点では、既に多くの回答があるようなので、別の観点から。

　オンライン系の処理ではあまり関係有りませんが、バッチ系の処理においては、データ量

（総データ量、処理対象データ量）によっては、RDBですと十分なパフォーマンスが得られず、

ファイルベースの処理のほうが適している場合があります。

入力データをフラットファイルに保持し、処理の先頭でファイルを読み込み、データをメモリ

上に展開して処理を実行、処理結果はフラットファイルに出力する、というやり方です。

このような場合に、XMLを採用することによりデータ構造の柔軟性が確保できる、というのは

大きなメリットになります。

「ただしあまり一般的に認知されている考え方ではない。」ということも付記しておきます。