XMLデータベースの研究しているのになんですが、僕個人としては
XML形式でデータを管理することはお勧めしません。
XMLデータを手で記述するなんていう作業はもってのほかです。
XMLは一部を間違って操作するだけで、全体がよくわからないデータになります。
Gmailで動的データ通信に使われているAJAXという技術もあって、この最後のXはXMLのことなのですが、データのやりとりはXMLでいいけれど、データの操作はXMLでないほうがいいとさえ思っています。
けれど、これをお勧めできるようにする技術の研究をしています。
企業の方などで、XMLデータベースを導入しようとしている考えている方は、
それよりも、まずrelational databaseのことを学んでください。今のrelational databaseにできなくて、XMLにできることは、そう多くはありません。逆にXMLにできないことの方が多いくらいです。
けれどこれはSQLを学べということではないのです。データベースを操作する言語なんて、データを取り出せて、安全に更新できれば、なんでもいいのです。それと同じように、XMLを操作する言語も乱立していますが、どれを使おうとどうでもいいことなのです。
XMLを使っているけれど、XMLを操作している印象を持たせないようにすることが、僕の当面の目標です。
License
 | Leo's Chronicle by Taro L. Saito is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.1 Japan License. |
3 件のコメント:
そうすると、RDB と比較した場合の XML データベースの利点って何なんでしょうか？
RDBを使う時、スキーマ（テーブルに含まれるデータ型）を定義し、テーブル間の関係を定義する必要があります。 けれど、最初から完璧なスキーマを作るのは難しいですよね。ruby on railsでの開発もそうなのですが、スキーマをアプリケーションの要求に合わせて、拡張したり変更していきたくなります。
その点、kick startで使い始めることができるのがXMLデータベースの利点です。スキーマを作成せずに、データを放り込んで置けるrepositoryとしてのメリットが大きいです。それでも、タグ付けされているデータなので、通常のファイルシステムと違って、データを検索しやすいというメリットがあります。
また、XMLは階層化されたデータであるので、従来のフラットファイルと違って中に含まれるデータの一部分を取り出したいなどの要求に応えることができるようになります。
いろいろなデータを表現するのに、XMLは不自由の少ないデータフォーマットです。バイナリを埋め込むこともできます。この点から僕は、XMLデータベースは、次世代ファイルシステムのベースとなるものだと見ています。
タグ付けされたデータをRDBで扱えないかというと、そういうことはないですよね。一つのrow（XMLのノードに対応）に対して、そのrow idと、tagデータを結びつけるテーブルを用意するだけです。
ただ、ディスク上のフォルダを考えてもらうとわかるのですが、フォルダをいくつか辿って、この位置にあるデータを取りしたい、ということはよくあります。 BOM（製品の部品表）もこのようなツリー型のデータです。この手の操作は、recursiveにjoinを行うことになるので、RDBにもXMLDBの用に階層データに特化したoptimizerや問い合わせ文が欲しくなります。でも、これはRDBがBOMに対応すればいいだけのこと。
そもそも、XMLでは無用な階層ができることが多いのです。タグの上下関係を入れ替えても、データとしては意味が通じることがあります。つまり階層に意味がない状態が存在します。XMLには悪い意味での自由度が多すぎます。意味の乏しい階層構造をＤＢで一生懸命管理するなんて…変な話なのです。
XMLDB でも、RDBのようにデータ型は定義して使いたいということになると、XMLの階層のあちこちのノードに対してデータ型を定義することになります。そうすると、データ構造がばらばらの状態では、データ型を、どの部分に定義すればよいか困ってしまうので、結局スキーマを使って、XMLの木構造を固定することになります。
木構造を固定できるということは、無意味な階層を排除して、RDBのテーブルの組み合わせだけでデータをうまく表現できることにつながります。テーブル操作だけなら、20年のノウハウがあるRDBの方が当然強固だし、optmizerも賢いです。
コメントを投稿