人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

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

●質問者: pkb_wn
●カテゴリ:コンピュータ
✍キーワード:MySQL Oracle RDB SQLServer XML
○ 状態 :終了
└ 回答数 : 8/8件

▽最新の回答へ

1 ● mizki101
●20ポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◎質問者からの返答

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


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

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

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


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

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

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

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

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


2 ● dev_zer0
●20ポイント

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

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

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

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

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

# 容量計算も面倒ですし


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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

◎質問者からの返答

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


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

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

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

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

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

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


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

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

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


3 ● yunoka
●20ポイント

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用の何かを用意してというよりは、

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

◎質問者からの返答

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


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

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

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

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

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


4 ● pigment
●20ポイント

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

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

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

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

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

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

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

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

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

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

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

◎質問者からの返答

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


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

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

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

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


5 ● deep_one
●22ポイント

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


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


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




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


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



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


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

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



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

◎質問者からの返答

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


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

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

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

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


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

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


1-5件表示/8件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ