◆ On Memory（一般にはIn Memory）という言葉に飛びついてはいけません。
学生が実験室で横のものを縦にして、ある特定の条件で性能が高くなると
いう事実を発見したからと言って、実業の分野ですぐ取り入れるのは、
余程の趣味人かその道の研究者でもない限りあり得ないでしょう。

◆ On Memoryはターボデータの場合、縦に情報を捉えて、独自のデータ形式、
独自の集合のアルゴリズム（LFM技術）で処理しているので、習熟した
エンジニアで、かつ特定の条件でなければ期待するパーフォーマンス
は得られません。　このエンジニアの育成には半年以上掛かり、教育投資が
必要になります。この製品を使いこなすコストは無視でない筈です。　
ターボデータのDayDa.Labooエンジンのユーザの約半数は、購入して導入した
ものの現在は使われていないです。

◆ 真偽のほどは分かりませんが、SAPやSUNが富士通BSCの「Oh-Pa1/3」をISV
に認定したとターボデータは言っています。　しかしISVとは、SAPやSUNは
一切責任を取らないという条件付きで、世の中には「こういうものもあり
ます」という紹介程度で、何のオブリゲーションも無いのものです。本当に
優れて実用的なものであれば、明らかに自社製品に採用している筈ですが、
採用したという話は聞いていません。
富士通は、富士通BSCという子会社で販売していますが、本腰を入れたという
訳ではないようですし、日立はRH-BOMという特定のアプリケーションで使用
しただけ。日立もRH-BOMはビジネスにはなっていないようですし、Oracleや
Microsoftは今のところターボデータには見向きもしていないようです。

◆ ターボデータの問題点
第一に使い難さが挙げられます。　プログラミングレス、マウス一つで
出来るというのは？　実際に業務に組み込むことになれば、APIは難解。
Object Orientedには程遠いものです。　CないしはC++の技術を持った
エンジニアが相当作り込まなければなりません。

第二にDayDa.Labooは、例えばSQLのような技術は使えません。　

第三にLIFITというGUIは、プログラミングに相当するMacroのドキュメント性
は全く考慮されていません。

第四に、何よりも特定の条件（SORTなど）でしかパーフォーマンスがでません。　

第五には、製品品質の問題が挙げられます。　ターボデータの商品は、
Student Codingと言われるほど製品品質が悪いようです。加えて製品の
保守や教育のサポート体制は何もありませんし、業務で使うソフトウエア
としてはNGです。

第六に、ターボデータが販売しているBI Tool Likeのパッケージの
「ザ･ターボ」（DayDa.Laboo＋Lifitのシングル・ユーズのWindowsベース
のパッケージ商品）は、クライアント・サーバ型でエンドユーザ・
コンピューティングという昔流行ったコンピューティング・スタイル
ですが、これではクライアントに金ばかり掛かってしまいます。いささか
時代遅れのコンピューティング・スタイルです。

第七に、BI Tool のターボ製品について、例えば32ビットで１Gバイト
のメモリーを搭載したパソコンで20億行もの大量のデータをどんな人が
必要としているのだろう？　　（64ビット4〜16GBでマルチCPU、メモリー
シェア対応のシングル・ユースのターボを開発中で1兆行まで可能だと
発表しています。）　またそれほどの大量のデータを扱うとすれば、セキュ
リティとか別の問題が出てきます。

◆ 確かにOn Memory DBは、時代の流れであることは間違いないでしょう。　
これからもOn Memory DBは次々出てくるでしょう。この完成度の低い特殊な
エンジンがこのままで普及することは有り得ないのでは？と言うのが感想で
すが、他のOn Memory DBはどうなんでしょうか？