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

["中山裕雄" <hnaka@xxxxxxxxxxxxxxx>]

生越様　お忙しいなか、早速のご説明ありがとうございます。

>   私は「業務システム」の根幹はサーバで動かすべきだと考えています。です
> から、「処理」を端末の方に持って行ってしまう危険性のある方法は、賛成出
> 来ません。

総論的には私もそう思います。
ただロジックはサーバーで（たとえばストアドプロシージャ）行う方法
が現時点は多いように思います。（これは素人の単に印象です。）
Javaアプリはあくまでもデータ入力の入り口として考えています。
あるいはMSAccessとかFileMakerでも同様の位置づけです。

>   最近は多くのシステムで、クライアント側でアプリケーションを動かして、
> サーバはデータベースだけというアプローチが流行っていますが、これはCPU
> パワーを浪費しないと儲からないというメーカの都合とか、マトモなトランザ
> クションモニタを作らないデータベースメーカの都合とか、マトモなアプリケー
> ションサーバを作れないOSメーカの都合とか、ユーザを覇権争いのネタとしか
> 思っていないメーカの都合とか、そういったユーザの都合とは関係ないところ
> での都合に過ぎません。
>
> > pandaと共存しながら、JavaアプリがダイレクトにPostgreSQLへ接続する
> > 方向は問題がありますでしょうか？
>
>   障害復旧のメカニズムを崩壊させる危険性があるので、問題大アリです。
>
>   今はPostgreSQLの上にいろいろなオブラートをかけて、リカバリや二重化
> (多重化)を実現しているのです。pandaのソースのaps/dbgroup.cより下の層へ
> の直接アクセスは、その辺の諸々を破綻させるので、厳禁です。
−中略−

>   他のシステムでやって下さい(きっぱり)。

了解しました。今後はもしJavaやAccessでUIを作った場合、
生越様の禁じ手である旨、承知の上（自己責任で。）
orcaの一部利用を行いたいと思います。

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

> > 電子カルテ部分がORCAとどういう方針接続されるのか明らかにされていないので
> > もしそのあたりも現時点での開発方針がもうすこし知りたいというのが
>
>   電子カルテには直接タッチしていませんので、わかりません。ただ、電子カ
> ルテがORCAのデータを触る時には、wfcを経由するか、CLAIMを使うかになるで
> しょう。それ以外のインターフェイスを公開しませんから。

この情報も実にありがたい情報です。
これで共存を目指すなら、CLAIMにするか
共存をあきらめてORCAのDB部分のみを
利用するか方針が立てやすくなりました。
貴重なご指導ありがとうございました。

中山小児科内科医院
中山裕雄