mb_language("uni"); mb_internal_encoding("utf-8"); mb_http_input("auto"); mb_http_output("utf-8"); ?>
第13回:後書き ~実装してみて気付いたこと~
これまでの記事では、住所録アプリケーションの開発を通して、WebアプリケーションのデータベースとしてXprioriを利用する場合の実装方法を紹介してきました。
今回はこれまでの記事を振り返り、Xprioriの持つ良い点や気になった部分を総括したいと思います。
Xprioriの便利な点
● スキーマ設計が簡単
RDBを利用したアプリケーションは、スキーマ設計が非常に重要です。開発の途中でスキーマ変更が発生すると膨大な修正コストがかかるため、実際に開発をはじめる前に、スキーマ設計を完成させる必要があります。
この過程は、アプリケーションの全体を見渡す能力が必要であり、それには実際に幾つかアプリケーションを開発した経験が求められます。
RDBに対してXML DB、特にXprioriはスキーマ設計が非常に簡単です。第11回と第12回の記事で紹介したようにXML DBは実装の途中でフィールド追加などのスキーマ変更が発生しても、修正コストが少なくてすみます。ですので開発の途中で柔軟にスキーマ変更を行うことができ、初期のスキーマに完全性が求められません。最適なスキーマを最初に決定しなくても、開発を進める上で細かいスキーマの調整を行っていくことが可能です。
● XPath・XQueryが利用できる
RDBにSQLがあるように、XML DBにはXPath,XQueryがあります。XQueryはこのシリーズでは利用しませんでしたので、ここではXPathに焦点を当てます。XPathにはposition関数など、SQLには無い関数が用意されています。この関数を利用することで第04回で紹介したページング機能の実装が容易に行えます。もちろん、XPathは階層構造をもつデータを対象としており、SQLは表のようなフラットな構造のデータを対象としているため、一概に比較して、どちらが優れているということはできません。しかし、元々が階層構造をもつデータを取り扱うアプリケーションの場合は、フラットな構造にデータを置き換えて格納したRDBからデータを取り出すためのSQLよりも、階層構造のままデータを格納したXML DBからデータを取り出すXPathのほうが使いやすいといえます。
● 広く使われている
Xprioriの製品版であるNeoCoreXMSは国内トップシェアのXMLデータベースです(https://www.cybertech.co.jp/)。そのためNeoCoreXMS/Xprioriのことを扱った技術ページもたくさんあり、開発で壁にぶつかったときの解決策を探しやすいといえます。実際にこのシリーズを執筆する上で、幾つかのページを調査し、NeoCoreXMS/Xprioriを扱ったページが多いことを実感しました。
Xprioriの不便な点
● 初期データが必要
第5回でデータベースに新規アイテムの挿入する方法を扱ったときに、address_book要素の下にitem要素が何も入っていない場合は、dummy要素の直下にitem要素を挿入するという処理を紹介しました。Xprioriでは完全に新しい子要素を作る手段が無いので、address_bookの子要素に本来ならば存在しないdummy要素を、初期データとして設定しておく必要があります。これは厳密なスキーマが存在しない、やわらかいデータベースだからこそおきる問題であり、RDBに慣れている開発者からみると、違和感を覚える部分かもしれません。
● スキーマ変更発生時の既存要素の編集
前回の第12回では、スキーマ変更が発生したときの、変更前の要素を更新する方法について紹介しました。ここで行った修正は、スキーマ変更に伴う修正のうち最もコストがかかる部分です。APIのmodifyXML関数が、指定した要素を置き換える処理の際に更新する要素の比較を行わない仕様であれば、より柔軟なスキーマ変更への対応が可能になると思われます。
● インジェクション対策
第9回ではセキュリティ対策の1つとして、XMLインジェクションとXPathインジェクションへの対策を紹介しました。XPathのconcat関数を利用したgetXpathConcat関数を用意することで一応の対策はできましたが、欲を言えば、多くのプログラミング言語で「\」をエスケープ文字として使用することができるように、特定のエスケープ文字を使用できるようにしてほしいところです。XPath2.0のドキュメントには
もし、リテラルがシングル・クォーテーションで区切られている場合、リテラル内の2つの隣り合ったシングル・クォート文字は1つのシングル・クォート文字と解釈されます。同様に、もしリテラルがダブル・クォーテーションによって区切られている場合、リテラル内の2つの隣り合ったダブル・クォート文字は1つのクォート文字であると解釈されます。 |
とありますので、XPath2.0では文字列を囲んでいるクォート文字が入力された場合は、それを2つ並べることで単独のクォート文字と解釈させることができるように、つまり、「"Hello!! ""Xpriori!"""」の場合は「Hello!! "Xpriori!"」と解釈し、「'Hello!! ''Xpriori!'''」の場合は「Hello!! 'Xpriori!'」と解釈する仕様になるようです。Xprioriの今後のバージョンアップに期待しましょう。
シリーズで扱わなかった部分
● ソート
このシリーズで作成した住所録アプリケーションではソート機能は実装しませんでしたが、Xprioriを使って、ソートされた状態での検索結果を取得したいということは、今後でてくるかも知れません。そのようなときの対応方法を少し紹介します。
SQLではORDER BY句を利用してソートが可能です。例えばaddress_bookというテーブルから郵便番号(フィールド名はzip)でソートしたい場合は
SELECT * FROM address_book ORDER BY zip |
となります。
これと似たような処理を行う場合は、XQueryのsortby式を利用することができます。SQLの場合と同じように、郵便番号(zip要素)でソートしたアイテムを取得する場合は
/ND/address_book/item sortby(zip) |
となります。item要素を指定したXPathの最後にsortby式を追加し、引数としてソート条件を渡します。このsortby式を利用することでWebアプリケーションにXprioriを使ったソート機能を追加することができるでしょう。なお、デフォルトでのソート順は要素が格納された順番です。
● フレームワーク
今回はstruts等のフレームワークを使わない、シンプルなWebアプリケーション開発を行ったため、JSP内のコード埋め込みがやや多いものとなってしまいました。フレームワーク技術に依存しない基本的な方法論を説明するためあえてフレームワークを利用しませんでしたが、実際の開発では、MVCモデルに即したstrutsなどの新しいフレームワーク技術と組み合わせた開発をしていただきたいと思います。
結びに
今回の記事で、このシリーズは終わりとなります。このシリーズを通してXML DBを利用したアプリケーション開発がどういうものかをつかんでいただけたのではないでしょうか。これからのWebアプリケーション開発は、無条件にRDBを選択するのではなく、アプリケーションで扱うデータに応じて、RDBを利用するか、XML DBを利用するかを選択する方向に進んでいくことでしょう。開発者としては、どのようなデータ構造がXML DBに適しているかを判断することが必要となります。
このシリーズが、XML DBを実際に用いた開発の流れや、RDB開発との相違点を理解する上で、お役に立てれば幸いです。
▲このページのTOPへ