[orca-users:00253] Re: ORCA for Mac OS X

[ogochan@xxxxxxxxxx]

生越です。

> ただロジックはサーバーで（たとえばストアドプロシージャ）行う方法
> が現時点は多いように思います。（これは素人の単に印象です。）

  素人の印象と言うか、宣伝に騙されているのでしょう。現実は、「なんとな
く適当にやっちゃってる」システムが氾濫してますから。

# 某病院の「動かないコンピュータ」はこれが原因でしょう

  クライアントにインテリジェンスを持たせるアーキテクチャの場合、「どこ
からどこまでをどっちでやるか」が常に問題になっています。DBの更新とか画
面制御のような白黒はっきりしたものであればいいのですが、それ以外の「ど
ちらでも出来る」ものに関しては、あいまいなことになります。

> リカバリや二重化が最大の「売り」だということは解りましたが
> non サポートでORCAを使う場合、いかにシステム管理を医院側
> （開発側ではなく。）が楽にするかということに関して、今のORCAが
> 本当に楽かどうか今のところ実感できません。診察中にDBごと
> クラッシュした場合を想定すると少なくともnonサポートで30分以内に予備システム
> が動作できるレベルに院内の態勢が整っていないと実務では使えませんから。

  現状、正しく二重化してあれば、すぐ予備系に切り換えれますけど。元々そ
ういった設計ですし。設定についてはいろいろありますが、そのうち簡単にな
るでしょう。

  ノンサポートの危険性があるからこその二重化です。壊れたら、壊れた方を
修理に出しても、そのまま業務が続けられる。これが基本仕様を「2台構成」
にした最大の意味です。

  さらに、センターにリアルタイムバックアップをしている場合、バックアッ
プセンターをASPにして業務続行が可能です。現在のアーキテクチャは、そこ
まで考慮されているのです。クライアントにインテリジェンスを持たすタイプ
の設計をしていたら、逆立ちしても出来ないでしょう。

> これで共存を目指すなら、CLAIMにするか
> 共存をあきらめてORCAのDB部分のみを
> 利用するか方針が立てやすくなりました。

  wfcにインターフェイスを取る方法を強くお勧めします。

-- 
ogochan@xxxxxxxxxxxxxxx           ->  http://www.jmari.med.or.jp
Masami Ogoshi                     ->  http://www.nurs.or.jp/~ogochan/
HarvestHouse 702 2-16 Maruyama-cho Shibuya-ku Tokyo 150-0044 JAPAN