永続データのアクセスパターン

インターシステムズの基礎テクノロジーである多次元データエンジン（あるいは多次元データストア）は、一般的にはデータベース技術と捉えられていますが、データベースよりは、もっと範囲の広いものを対象にしているように思います。

そういう観点からデータベース技術と区別する意味で永続データマネージャという言い方をしています。

一般的なアプリケーションでの永続データの使われ方は、大きく分けると以下に集約されるのではないかと思います。

• 基本情報（マスター）データ
• トランザクションデータ
• メタ（スキーマ）データ
• 構成、設定管理用データ
• ワークデータ
• 状態保持用データ

一般的にデータベースといわれるものは、基本情報データとトランザクションデータで、これらは、２次利用を含めてライフサイクルという観点では、一番長生きだと思います。

ですので、これは共通にアクセスするしくみSQLのようなインタフェースが欠かせません。

メタデータは、データベースに欠かせないものなので、データベースの一部と考えることも可能です。

ワークデータは、DBMSのソート用のワークデータも含まれますが、ここでは、アプリケーションプログラムが使用するもっと広範囲のワーク（一時的な）データを含みます。

アプリケーションには様々な構成、設定情報を必要とするケースがあります。

状態保持用には様々なケースが考えられますが、複数プロセスが連携する際のちょっとした情報交換用などです。

一般的なアプリケーションでは、これらの様々な用途の永続データを様々な手段で実装しているケースが多いと思います。

構成情報は、XMLファイルだったり、状態保持用には共有マップだったり、単純なファイルだったりという感じです。

個人の裁量というか、得意、不得意で実装方式が決められたりもします。

インターシステムズのプログラミング言語では、これらのほとんどは、永続変数として保持できます。

これは、非常に簡便に使用することができますが、想像以上に強力です。

例えば、構成情報をXMLファイルで保持すると、後々ファイルが増えた場合に管理が煩雑になりますが、XML構成情報を永続変数の形で保持すると管理が楽になります。

その他、ちょっとした情報を永続データの形で簡便に保持できて、あとですばやく簡単に使えるというのは、プログラミング労力を軽減することに絶大な力を与えます。

地味なことですが、つもり積もれば効果絶大です。

しかし、これは実際に体験しないことにはなかなか理解できないことの１つでもあります。