XQuery
仕事のプロジェクトの関係で、処理対象の種別によってデータ項目が可変って厄介なシステム扱うのに、SQL/XMLはどーよ？って話になって、XQueryとかSQL/XMLとか調査してるんだけれども。
なんつーか、最初幻想抱きすぎてたのが悪いのか、だいぶガッカリでRDB+XMLって意味あんのかコレって気分になってきたりして。。。
最大のがっかりは、
「XML上のデータを扱う場合とRDB上のデータを扱う場合は、結局別枠」
コレに尽きる。
例えば、IDに対する名前を管理しているテーブルと、そのIDを参照してるXMLがあった場合、XMLのIDから名前を引く為に色々手間隙踏まないと駄目ってのが頭悪すぎる。
RDBであれば、表結合して簡単に持ってこれるよなーって想像できるのに、いっぺんどっちかの形式に統合しないと結合出来ないんだもんなぁ。
それだったら、最初っからRDBの部分切ってXML DBでまったく問題ないじゃんって感じが。。。orz
RDB+XMLって形式になってる以上、XMLのデータとRDBのデータの間でリレーション張れないと詐欺だと思うんだけどなぁ、どーなんだよ、その辺り。
上の例で行くと、RDBだけなら名前管理してるIDが参照されてたら削除不可能とか参照先も自動消去とか出来るのに、XML側からの参照だとまったく無頓着ってのはね、流石にどーなのかね明智君。
今の仕様だと結局XMLだけでデータ管理した方が遥かに楽で、１行でXMLデータを格納するテーブルばっかりたくさん作るって作りが一番マシって感じがするんだが（汗）
それって、RDB部分要らんよね。
（まぁ、インデックス『は』作れるんで、ふつーにXML解析するよりは高速なんだろーけど）
ただ、その場合に困った事にXML操作の部分担当してるXQueryが、統計処理とかに関してはSQLにまったく及ばないんだよなぁ。。。
なんという痛し痒し。
あと、XQueryに関しても困った事に、コイツ使うとMVCモデルも三層モデルもへったくれもねぇって事だよなぁ。
XMLからHTMLに変換するときに、結局効率重視するならXQuery内で生成しなくちゃならないから、その時点でMVCも三層も崩壊しちゃうんだよなぁ。
なにしろ画面定義してる筈の部分でSQLやら何やらゴリゴリ書かなければいけない訳で、その上表示上の制約加えたりとかもXQueryで解決しないと駄目なワケで・・・ってなると、もう超スパゲッティ。
なにしろ、JSPだけでビジネスアプリ完成させろって言ってるよーなもんだからなぁ（汗）
しかも（DB2に関してかもしれないけど）、XQuery部分のステップ実行等のデバッグ操作は不可能、と来たもんだ。
バグ出たら泣くぞ、コレｗ
XQueryと上部アプリのデータのやり取りも、DB介さないと不可能っぽいしなぁ。
ちょっと使いにくすぎる。。。
#さらに、XMLのデータを更新するのはXML文書全部ってゆー現状の制限がね。もぉね、致命傷。
トラックバック URL :