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


データをリレーショナルデータベース(OracleやSQLServerやMySQLなどのRDB)ではなくて
XML型のデータベース(木構造データベース?)もしくはXMLファイルに大量にためることについて
何か利点を見出すことは出来ますか?
どのようなシステム仕様、ジョブ設計、データの特性、データ操作、開発・保守作業、その他の場合において有利でしょうか?

私自身は、XMLの恩恵にあまりあずかっていないのですが
だんだんと普及しているようですので、何か利点があるのだろうと思い、質問してみました。
(否応なく使わざる得ない場合には使っているが
手編集は面倒くさいし、データをぱっと見ても俯瞰しにくいし、XMLでこそ!といった用途がぴんとこない・・・)

質問から的が外れていなくて沢山挙げていただいた方に高ポイントを差し上げたいと思います。
(あえて人力検索で質問します)
宜しくお願い致します。

回答の条件
  • 1人3回まで
  • 登録:2009/05/08 03:10:31
  • 終了:2009/05/14 00:25:07

回答(8件)

id:mizki101 No.1

mizki101回答回数209ベストアンサー獲得回数52009/05/08 04:33:16

ポイント20pt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

id:HISI

どうも有り難う御座います。


XMLの検索もやがて研究がすすめばより速くなるのでしょうが、現段階ではRDBのような単方向の検索・走査はとても及ばないでしょうね。

RDBの検索(アクセスパス、クエリー実行プラン)をみてみると、長い年月かけて積んできたコンピュータ界の技術のすばらしい結晶だと思います。

先人が悩みぬいた技の集大成というか。


リンク先のページを拝見すると、部品などの構成情報や文書には、XMLが向いているようですね。

RDBが動かない堅い箱に敷き詰められている一方

XMLの場合はその木構造そのものも情報(データ)であって、

木構造の一部をはがして別のところにくっつけたりするなど

XMLならではの便利な操作を習得すれば積極的に生かす場が増えて好きになれそうです。

2009/05/09 02:15:49
id:dev_zer0 No.2

dev_zer0回答回数332ベストアンサー獲得回数252009/05/08 10:55:59

ポイント20pt

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

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

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

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

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

 # 容量計算も面倒ですし


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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

id:HISI

どうも有り難う御座います。


RDBの場合データを複数の表に正規化する作業など必要になりますが(更新がなくて検索だけなら不要かもしれませんが)

XMLは繰り返し構造も許容できたりする分、また別の規則があるのでしょうね。

そのXMLの自由さゆえに、私にとって

ある値をどのような場合に要素の間に入れたらいいのか、あるいは属性として登録したほうがいいのか、など

構造の判断基準がわからなくて、XMLの構造の意義(どうしてこのような形にしたのか、といったこと)を見出しにくい状態です。

cとどう違ってどちらがどういうとこに有利なのか...など。


データのオフセットが固定な(VARCHARなどもあるにはありますけれど)RDBに単方向の検索は軍配があがるのでしょう。

とはいえ、互いに特徴があるRDBとXMLとは、住み分けたり補い合ったりしていくものなのでしょうね。

もっと研究してみたいと思います。

2009/05/09 03:16:17
id:Yunoka No.3

yunoka回答回数27ベストアンサー獲得回数32009/05/08 18:00:30

ポイント20pt

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

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

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

RDBだとどうしても2次元の表になってしまいがちで、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用の何かを用意してというよりは、

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

id:HISI

どうも有り難う御座います。


確かに1つ1つのもの(インスタンス)が不揃いで多彩な情報をもっている場合にはXMLは強そうですね。

RDBだったら将来のまで考えて表や列を沢山つくったり(NULLだらけでスカスカ)するところも

XMLであれば場当たり的に無駄なく作れそうです。

そのかわり、検索する場合を考えて属性や要素の意味と名前を全体で統一しておいたりすることが大切になるでしょうね。

(もっともRDBでも、キーの型や名称を統一して1Fact1Placeを守らなくてはなりませんが。。)

2009/05/09 03:05:39
id:pigment No.4

pigment回答回数95ベストアンサー獲得回数22009/05/08 12:47:55

ポイント20pt

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

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

1.保存できるデータ数に上限を持つ

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

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

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

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

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

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

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

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

id:HISI

どうも有り難う御座います。


XML型を格納できるRDBは、XMLをよく知れば使いこなせる場面は結構あるかもしれませんね。

ものによってはどうしてもカラム内だけではなくて、

スキーマ全体の大枠ごとXMLにするほうがうまく表現、活用できる状況というのもあるのでしょうが。。

XPATHはよく勉強してみたいと思います。

2009/05/09 03:11:34
id:deep_one No.5

deep_one回答回数91ベストアンサー獲得回数72009/05/09 09:30:00

ポイント22pt

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


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


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




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


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



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


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

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



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

id:HISI

どうも有り難う御座います。


なるほど、木構造の特徴を生かしてデータの特定部分を修飾していく(人物の情報、読み仮名など)用途に向いていそうですね。HTML(SGML)の特色そのものでもありますし。

XMLの場合、RDBのように行(インスタンス)を積み上げていくイメージ(インスタンス間の連携は無機的)ではなくて

インスタンスの範囲はXMLファイル全体でもあり部分でもあり概念として自由で(ここをDTDで定義して縛っているのだと思いますが、あまり理解できていません)

そこが余計に自分を惑わせているようです。すみません、あんまりXMLを理解できていないもので・・・


XML-WEBサービス(WEBAPI)もクラウドコンピューティングなどで普及していくでしょうし

XMLは今後いっそう避けて通れなくなりそうです。

2009/05/09 14:43:14
id:pigment No.6

pigment回答回数95ベストアンサー獲得回数22009/05/13 11:43:36

ポイント20pt

別の例

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

部署名

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>

ということが出来ます

id:HISI

どうも有り難う御座います。


<depart>

<name>A部</name>

<person cd="0001">Aさん</parson>

<person cd="0002">Bさん</parson>

<person cd="0003">Cさん</parson>

</depart>


と表したり


<depart>

<name>A部</name>

<person>

<cd>0001</cd>

<name>Aさん</name>

</parson>

<person>

<cd>0002</cd>

<name>Bさん</name>

</parson>

<person>

<cd>0003</cd>

<name>Cさん</name>

</parson>

</depart>


とも表せるんですよね。

どんな特徴が実際のデータアクセスであるのか、どんな概念的なデータの意味の違いがあるのか・・・

2009/05/14 00:07:11
id:takano32 No.7

takano32回答回数58ベストアンサー獲得回数52009/05/13 11:52:02

ポイント20pt

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

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

id:HISI

どうも有り難う御座います。


XSLTは、XML特有というよりはRDBのビューのような位置づけでしょうか。

RDBのような正規化は行わないかもしれませんが(繰返しデータも表現可能など)

XML特有に気をつけることがあるとは思っています。

2009/05/14 00:24:03
id:lipper No.8

lipper回答回数33ベストアンサー獲得回数22009/05/13 19:32:39

ポイント22pt

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


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

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

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

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

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

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

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


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

id:HISI

どうも有り難う御座います。


実は、国内の超大手SIerさんが

自社の基幹システムのデータ(受発注情報、生産情報、会計情報、他あらゆる基幹情報)の実績系情報を

基本すべてXMLで吐きまくって管理する(XMLでデータをためる:ファイルなのかDBなのか不明)システムに移行した

という情報を聞いたので、どんな利点があるものか質問してみました。


XMLのファイルごとに任意の構造のスキーマ定義をもっているので、

それらXMLファイルから

それぞれの処理が望むデータ(要素や属性)だけをピックアップしてデータ処理が出来るようになるわけですね。

2009/05/14 00:18:10
  • id:dev_zer0
    > ある値をどのような場合に要素の間に入れたらいいのか、あるいは属性として登録したほうがいいのか
    これはRDBでも同じでしょう
    正規化するべきか/しないべきか。項目の型をどうすべきかというのは
    あくまでRDBの設計技術を持っているから可能であって、
    持っていないと全部を1つのテーブルにして項目数が数百個とか
    あるいは正規化にこだわりすぎで数個の項目数のテーブルが数百個作ってしまったり
    知ってる人から見ればヘンテコリンな設計になってしまう可能性が高いです。
     
    XMLのスキーマ設計でも同様に設計を行うにはある程度の技術と場数が必要です。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません