MUMPS好き好き。コミュのMUMPSとCache'（キャシエー)

何でしょう？(笑)

私の希望は、MUMPSにSQLやオブジェクトの考え方を入れる(今のCache'の方向)のと同時に、Javaや.Netなどのプラットフォームや、PyhonやRuby、Perlなどのスクリプト言語にMUMPSの考え方(グローバル変数：DB)を取り入れてほしいと思います。

VisM(VBなど)やWebLink(Web)、m_php(php)では、MUMPS(グローバル変数)の柔軟さシンプルさを失わずに新しいツールと統合出来ているのですから・・・

オブジェクト指向の言語を使っても最後はRDBとのマッチングで苦労するらしいですから、いっそDBはMUMPSのグローバル変数を使えばいいと思うのですが・・・なにか問題ありますでしょうか？(笑)

Cache'データベースのクラスを定義する場合、
%Library.Persistent
という永続型クラスを継承させます。
スーパークラスPersistentは、メモリー上のインスタンスでなく、Close（インスタンス消去）しても、そのまなディスクに残るという意味で、要はDBですな。
しかし、当然メモリーインスタンスからDBへは %Saveメソッドを実行しないとだめです。
DBからメモリーインスタンスへ読み込む %Openメソッドや新規にDBインスタンスを作る(DBインスタンスのオブジェクトID=まあユニーク連番です=を採番する）%Newメソッドなど一連のDBアクセスのためのMethod,Property,Query,Parameterがすでに定義されています。
%Library.Persistentは、スーパークラス%RegisteredObjectを継承していて、インメモリーインスタンスの処理を行います。

%Library.Persistentスーパークラスには、StotageStratageというクラスキーワードがあり、DBに格納するときの方式（MUMPSのグローバルにどうインスタンスPropertyデータをマッピング格納するか）を決めます。

実DB(Persistent)クラスを定義する際、Storage（DB格納方法）を、これもスーパークラス
1) %Library.CacheStorage
2) %Library.CacheSQLStorage
3) %Library.CustomStorage
の３つから選びます。1)がデフォルト。

この選択がDBの構造、使い方、後の変更容易性・柔軟性、PureMUMPSからアクセスできるかを決めます。

1) CacheStorageは、Cache'おまかせで、Propertyの型（データ型、Single/Multi value、リストアレイ、キーワードアレイ、他のDBオブジェクトへのポインター=相手のオブジェクトIDをデータにもつ）により、$list関数(レコード構造体を文字ビット列に構成する関数)を使って複雑にネストしたレコード構造にした文字（バイナリー）列値をもつMUMPSのグロ−バルを作ってくれます。

DBのアクセスは、その格納構造を意識しなくてもよく、%Openでメモリーインスタンスにもってくると、そのメモリー参照オブジェクト oref.property でアクセス出来ます。 しかし、ここでは、PureMUMPSのコマンドでグローバルをアクセスすることはあきらめるしかなく、DB内部構造はブラックボックスです。クラスコンパイル時に生成されたMUMPSコード(InterSystems社）に頼るしかない世界です。
Cache'のクラス・スーパークラスは、基本的にクラスコンパイル時に、MUMSPコードを生成（Genereate）するジェネレーターの塊のようなもので、生成されたコードはPureMUMPSです(MUMSPをうまくラッピングしてますが実態はMUMPSです）。
この CacheStorage　がデフォルトのStotageStratageで、MUMPSグローバルの設計は不要です。そのかわり、Propertyとそのタイプ、DB間リレーション、インデックス、パラメータ等は最初に相当正確に決めておかないと、DB内部構造がブラックボックだけに、一旦データベースが蓄えられだすと、DBだけに（Persistentなだけに）、その変更は厄介です。
プログラムクラスの柔軟性・再利用とDBオブジェクトの構造変更・柔軟性は違うもので、MUMPSグローバルの持っていた、DBの構造柔軟性は失われると考えていいし、MUMPSグローバルのシンプルさも利用者からみて無くなると考えていいと思います（InterSystems社はそれをフルに利用出来ますが）。
そのかわり、グローバル設計不要、グローバルアクセスコーディング不要、オブジェクト的シンタックス set oref.property="..."　が可能、もちろんSQLアクセスも出来ます。
このメリット、デメリットをどう判断するかです。

2)の CacheSQLStorageは、Cache'の前身ISM/OpenM のMSQL（M=MUMPSグローバルのSQLマッピング）をべースにするものです。MSQLは、PureMUMPSで作ったグローバルを&SQL(sql文)マクロコマンド（これもPureMUMPSコードに展開される）で利用（コーディング）するためと、ODBCでMUMPS外部からグローバルをアクセスするために開発されたものです。
したがて、このStorage方式を採用すると、グローバルはPureMUMPSベースですので、自分でMUMPSグローバルの設計を行い、アクセスも出来ます。MUMPSグローバルをSQLやオブジェクトとしてみせるために、MUMPSグローバルの構造（メタ）データをStorageマップ情報として登録する作業が必要となります（この作業、1)では不要。Cache'が決めている、たぶん最適に）。
しかし、これを使えば、オブジェクトアクセス、SQLアクセスに加え、PureMUMPSアクセスが可能になります。
残念なことに、Cache'５以降では、1) CacheStorage がデフィルトというより、それが前提という感じで、2)の CacheSQLStorage はレガシー化させようというInterSystems社の意向が見えます。2) で一番厄介な、Storageマップ情報の登録方法やそのドキュメントが、ISM/OpenM の時代のMSQLではそれがメインであったのに、Cache'５以降、意図的か隠され見えにくくなって来ています。

3) CustomStorageは、%New,%Open,%Saveや、DBデータ（ポインター）から他DBデータ読み込み（Swizzling)、データバリデート(チェック）等全てのMethodを自前のMUMPSコードで書くタイプです（提供スーパークラスの助けなし）。MUMPS時代からCache'オブジェクトへの移行時にユーザが最後に何でも**やれば**出来る方式を用意くれたのでしょう(この考えすばらしいです）。

つーさん、したがって、PureMUMPSでのグローバルアクセスを行いたい場合は、2),3)しかないが、SQL(ODBC)アクセスを考えると、2)しかありません。

2)のメリットは、DBグローバルが自分でコントロール出来、MUMPSグローバルのシンプルさ、柔軟性が享受できること、最適化が必要な場合、PureMUMPSで性能をあげられることです。

1)も2)もオブジェクトシンタックスでDBアクセスが出来ますが、その生成されたコードを見ると PureMUMPS で　set name=^AAA(ID,"Name") でアクセスできるのに、コードは約10-100倍大きくなりオーバーヘッドがあります。それは当然で、まず、DBのオブジェクトIdを得て、%Open でメモリインスタンスに展開し（"Name"しかいらないのにそのオブジェクトIdのデータが全部（リファレンスオブジェクトIdのデータは除く）もってこられる）、そこで、set name=oref.Name でさらに展開コードが走る。簡単なテストで、PureMUMPSとオブジェクトアクセスは場合により100倍ぐらいの差出る。

当然、クラスの実装内部構造を隠蔽し、アクセス制限を行うオブジェクト志向は賛成だが、ことDBオブジェクトとその性能に関しては、2)は、業務性能の最適化のために必要な場合、DBアクセスのPureMUMPSコードで書けば高速化が可能という選択枝がある、また、グローバル構造がホワイトボックスなので、開発者から見るととても心強く安心感がある。さらに、ベースが MSQLなので、&SQL( )でデータが取れる(READ)。このSQLアクセスは、MUMPSグローバルの構造を知らなくても、ロジカルにグローバルデータが取れる。READ時は登録時のバリデーションがいらないので&SQL() で十分で、オブジェクトのインスタンスを作らないので性能もいい（簡単なテストでSQLアクセスはオブジェクトより3倍SEQが早い、当然PureMUMPSがもっと早いが）。
READ時はSQLで、WEITE時には、バリデーションがいるし、インデックスの整合性配慮もいるので、オブジェクトを使う。これが、前回スレの知恵の一端です。

デメリットは、オブジェクトDBの戦略のため、Intersytems社がそれをオブソリート化していることです。

WebアプリとDBオブジェクト（リレーションナルDBでも同じですが）とは相性的に難点があります。
セッションレス・ステートレスのWebアプリの場合、オブジェクトを使うと、セッション毎、DBオブジェクトのOpen・Closeを行う必要があり、無駄が多い。
DBオブジェクトをセッション継続領域（ステートあり）でもつと同オブジェクトがロックされた状態のままとなる。また、利用者はブラウザーｘボタンで終了した場合、それを早く検知する方法を作っておかないとロックがかかりぱなしとなる等々。


最近読んでいる本で、

軽快なJava

http://www.amazon.co.jp/exec/obidos/ASIN/487311201X/250-5666742-8066612

があり、面白いです。

複雑巨大なエンタープライズフレームワークとの付き合いがつらくて、Java嫌いになりそうな人や、今のJavaの世界に面倒で重苦しいものの気配を感じていてJavaを敬遠している人びとに、涼しい酸素の深呼吸をプレゼントする。

とあります。

Cache'もJava・.NETフレームワークの方向にあり、面倒で重苦しいものを少し感じています。