あなたは何をしたいですか?

  まず、はじめに考えなければならないことが2つあります。
  ・どんなアプリケーション・システムを構築するのか?
  ・新しい技術にチャレンジするのか?
  
  構築するアプリケーション・システムのデザインをすることは、ごく当然のことですが、Caché を利用する場合には 「その場面でどのデータベース・モデルを利用するか?」を検討する必要があります。 例えば、トランザクション処理を構築する場合には、SQLを利用するのか(つまり、リレーショナル データベース モデルを利用するのか?)、 あるいは、オブジェクト指向コマンドを利用するのか(つまり、オブジェクト指向 データベース モデルを利用するのか?)、といったことです。 Caché では、あるアプリケーション・システムは3つのデータベース モデルの中のどれか1つを選択して利用しなければならない、という条件はありません。 必要なときに、必要な方法を利用することができます。
  
  「新しい技術にチャレンジするのか/できるのか」は非常に大きな問題です。 技術的な問題であると言うよりも、ある種、経営的な問題であると言えます。
  例えばこういうことが考えられます。 「現在のアプリケーション・システム構築は、リレーショナル データベースを利用することを前提としてER図を使って設計をしている。 しかしこの方法を踏襲する限り、アプリケーション・システムの生産性は現在の30%までしか向上できる見込みが無い。 まして、メンテナンス工数に関しては、生産性の向上は見込めない。」この状況では、企業としての利益確保がどんどん難しくなってゆき 顧客へのサービス向上にも困難を来たす可能性がある、と判断したとします。 (実際に、顧客はコンピュータ・システムへの投資金額を削減する方向であるにも関らず、要求レベルはどんどん高くなっています。)
  このような状況を打破する方策はあるのでしょうか?
  「Caché を利用することで打破できます。」と私たちは自信を持って応えます。 Caché を利用することで50%もの生産性向上が可能であった場合が実際に存在します。
  しかし、Caché を利用することは非常に大きな「チャレンジ」です。大きな覚悟が必要です。 それは、Caché がエンジニアに求める技術(思考)が従来のそれとは異なる種類のものであるためです。 具体的には「オブジェクト指向技術」があります。「多次元データモデル」もそうかもしれません。
  
  Caché を利用するかどうかを技術レベルで判断することは、とても難しいのではないかと最近感じます。
  経営者レベルの視点で「今後、どうしてゆきたいか?」を良く考えて、Caché へのチャレンジ(このチャレンジはとてもエキサイティングで実利があります)を行えるのか 行えないのかを判断する必要があると言えます。
  
  なお、Caché はいかなる要求にも十分に対応する能力があることを付け加えておきます。

戻る