業務用システムを桐で作るのとオラクルで作るのとではどこが違うのでしょう

過去の桐井戸端ＢＢＳ　（桐談義・その他）

28859	業務用システムを桐で作るのとオラクルで作るのとではどこが違うのでしょう	肥田	2005/01/31-10:59
ご無沙汰してます。いつも貴重な情報源となって大変助かっております。相変わらずのビギナーです。ご了承ください。本来の質問とは若干異なるかも知れませんがお許しください。私は病院勤務ですが、昨今政府の経済政策の一環として医療情報のＩＴ化が急速に進んでおります。当院にもパッケージのオーダーリングシステムが導入されましたが非常に使いづらく、カスタマイズも皆無といっていいほどできません。他のシステムとのデータ連携はほとんど不可能ですし、それを依頼すると多大な費用を提示されます。オラクルで作られているとのことですが、最も処理に負荷がかかると思われる会計システムはアクセスで作られていてＯＤＢＣでオラクルと接続されています。規模にもよるとは思いますが、やってることは桐で十分可能なようにも見えるのですが、いったいどこが違うのでしょう？桐で不可能だとすればどのような点が問題となるのでしょう？莫大な費用を投じて、不便で使いづらいシステムが導入されるのに納得がいきません。もし良かったらご教授お願いします。
28862	Re:桐とオラクル	ONnoji	2005/01/31-13:50
記事番号28859へのコメント肥田さんは No.28859「桐とオラクル」で書きました。肥田さん、こんにちは。 >オラクルで作られているとのことですが、最も処理に負荷がかかると思われ >る会計システムはアクセスで作られていてＯＤＢＣでオラクルと接続されて >います。 >規模にもよるとは思いますが、やってることは桐で十分可能なようにも見え >るのですが、いったいどこが違うのでしょう？異論がある人がいるかもしれませんが… 以下はあくまでも私の個人的な感想です。オラクルは基幹業務で運用するデータベースとして定評があります。堅牢性、安定性、セキュリティ etc.を要求される場合には定番です。アクセスの方は、小回りを利かせた小規模システムを作る場合に使うことがありますね。オラクルと桐を比較するのは、まったく性質が違うもの同士なので意味がありません。しかし、アクセスと桐は似たものと言えなくもありません。病院内のあらゆるデータを一元的に管理しようとするのなら、オラクルを利用するのは一般的なことと言えると思います。会計システムで、オラクルからデータを引張ってきて、アクセスで処理するというのもうなずけます。この場合、アクセスの代わりに、桐を使うことも可能性としてはあります。しかし、開発業者がアクセスに慣れていも、桐には慣れていない場合が多いので、いとも簡単に候補から外れてしまうと思います。データベースの能力としては、アクセスと桐とで、それほどの違いはありません。どちらも、小規模なシステムを作るのに適していると思います。経営規模が小さな場合では、オラクルではコストが掛かりすぎるので、アクセスや桐を代わりに利用するということもあるでしょう。しかし、経営規模が大きければ、アクセスや桐には荷が重過ぎます。もちろん、豊富な資金を投入できるはずでしょう。 >当院にもパッケージのオーダーリングシステムが導入されましたが >非常に使いづらく、カスタマイズも皆無といっていいほどできません。 >他のシステムとのデータ連携はほとんど不可能ですし、それを依頼すると多 >大な費用を提示されます。これは、データベースに何を使うかの問題ではないと思いますよ。利用するデータベースが何であれ、アプリケーションの開発・改造を行うには手間と時間がかかります。この場合の時間単価が、健康保険が利かない医療費のように非常に高額だと言うことです。 >桐で不可能だとすればどのような点が問題となるのでしょう？ >莫大な費用を投じて、不便で使いづらいシステムが導入されるのに納得がい >きません。利用しづらいシステムというのは、世の中にた～くさんありますよ。変な例え話ですが、出来の悪いホームページでは、いつのまにか、迷子になっていったい自分が今どこにいるのか分からなくなったり、探したい情報がすぐに見つからなくてイライラさせられる経験が誰にもあると思います。つまり、「出来の悪いホームページ」も「出来の悪いアプリケーション」と同じですね。ホームページも業務アプリケーションも等しく実体はソフトウェアなのですから。残念ながら、利用者にやさしいソフトウェアの数が少ないのが現実の姿ですね。 >非常に使いづらくどんなに導入事例がたくさんあっても、どんなに有名な企業が開発していても、そのことと「アプリケーションの使いやすさ」は無関係だと思います。逆に、どこの誰が作ったかも分からないアプリケーションが、とても使いやすいことだってありますよ。気が付けば、長々と書いてしまいました。どうも失礼しました。（^^ゞ
28863	Re:桐とオラクル	宮城	2005/01/31-14:22
記事番号28859へのコメント肥田さん、こんにちは。私も病院勤務事務職ですのでわかる範囲でコメントします。まずは、内容はともかくとしてお値段。レセコンとオーダリングを導入されているのですね。病床規模にもよるのですが、エイヤっとみてそれぞれ、ン千万でしょう。一般的に病院向けシステム、ちょっとお高いんじゃないのということはありますが、このお値段です。不可能とはいいませんが、素人が家を建てると考えるとよろしいかと思います。システム構成から見ると、おそらくレセコンで1台、オーダリングでもう1台サーバーをたてているはずです。ではレセコンから。やっていることは患者情報、保険情報、病歴、点数計算ってところですね。前三者は桐で何とかなるレベルだと思います。問題は点数計算。「医科点数表の解釈（通称『アオ本』）」 1200ページ以上あり、2年に1度改定されるのはご存知のとおりです。まずこのボリュームを取り込みきれるか？正直なところ、複雑すぎてほとんど「ブラックボックス」の域に達しており、医事課職員でもレセコンなしには点数計算できないのが普通じゃないでしょうか。そのほかに点数体系には、労災・自賠・自由診療があります。さらに改定スケジュールたるや、2月頃から個別情報がチラチラ流れ始め、窓口適用は4月1日から待ったなしです。これだけはどう頑張っても到底素人の及ぶところではありません。改定内容をなんとなくアタマに入れるぐらいが関の山でとても自家製ロジックをいじっている余裕はありません。（ただし、薬科ではありますが、桐で実現されているかたはいます。）次にオーダーですが、うちの病院（１１１床です）でざっと見積もって、フルオーダーだと5万件ほどだと思います。実施が加わればこの2倍、さらに取り消し・変更にも対応できなければなりません。医療事故防止の観点からはいろいろチェックも入れたくなりますね。これをこなしてレセコンに渡してやれればいいわけですが、自信ありますか？ >当院にもパッケージのオーダーリングシステムが導入されましたが >非常に使いづらく、カスタマイズも皆無といっていいほどできません。 >他のシステムとのデータ連携はほとんど不可能ですし、それを依頼すると多 >大な費用を提示されます。このあたりはなんともいえないのですが、カスタマイズ・データ連携とも、すべておカネ次第だと思います。後は必要性との兼ね合いで、必要な機能ならいかにおカネがかかろうが対応してもらうか、どうしてもできないなら乗り換えるか、というところじゃないですか。ということで、なにができるか、なにを狙うべきかですが、いまどきのシステムですから、各サーバーからテキストを吐き出すくらいの機能はあるはずです。それをこちょこちょやればそれなりのことはできるものですよ。
28868	Re:桐とオラクル	コルネ	2005/02/01-09:01
記事番号28859へのコメント私も医療関係です。オルカプロジェクトにも関与した事もあります。 >当院にもパッケージのオーダーリングシステムが導入されましたが出来合いだから安いのでしょうね。アクセスの部分は桐でも可能だと思います。どうせ処理速度や負荷軽減のためデータ分離が必要ですから。１から開発するにしてもアクセスより桐の方が数倍開発期間は短く済むと思いますよ。ただ、パッケージよりも遥かに高価になってしまいますし、開発業者が居るかどうかですね。
28871	Re:クライアント＝サーバー」タイプのＤＢシステム	Ogo	2005/02/01-09:56
記事番号28859へのコメント一般的に言う「クライアント＝サーバー」タイプのＤＢシステムを組むのに桐が使えないか――という命題に対する一般的感触ですが。大前提として ○ 桐でシステムを構築することに同意する顧客は少ない。　（この業界ではメジャー指向が強いです。ＤＢシステムの様な　　長期間運用が絶対的条件になるような場合、発売元の経時的　　存続性や信頼性までも含めて吟味されるのは極めて当たり前。　　たとえアクセスが各バージョン間で互換性が無くても、　　ＭＳ　　製品であることで将来的に「ずっと使える」と考える人間が多いのが現実。） ○従って、桐でシステムを構築する業者も極めて少なく、逆に　そのことで、「あの会社に何かあった場合、どうなるんだ」的　不安という悪循環に陥りやすい。（続く）
28874	Re:「クライアント＝サーバー」タイプのＤＢシステム	Ogo	2005/02/01-10:38
記事番号28871へのコメントサーバーＤＢとして ○ 桐は全くサーバーとしての用途に向いていない。　画面表示と無関係な「サービス」として起動できない。　ODBC やその他の方法を使って、クライアントとの協調・共有　作業をする基本的機能がない（桐の「共有」はピアピアレベル）　概念として一般的にクライアント＝サーバーはこうなります。　┏━━━━━━━━━┓排他的占有┏━━━━━━━┓ 　┃ＤＢサーバーソフト　　┃←───→┃ＤＢ　　　　　　　　┃ 　┃(ＯＤＢＣドライバ)　　　┃データ処理　┃(テーブルのみ)　┃ 　┗━━━━━━━━━┛　　　　　　　　┗━━━━━━━┛ 　　　　│　　　　　↑ 　公開│　　　　　│データリクエスト　　　　↓　　　　　│書き込み要求　┏━━━━━━━━━━━━┓ 　┃クライアント（同時複数）　　　┃ 　┗━━━━━━━━━━━━┛ プラットホームが Windows の場合、サーバーとクライアントとのやり取りはＭＳの提唱する ODBC という規格（方法）を使うことが多いです（もちろん、実装さえしていれば、 ODBC 以外でも可）。桐はサーバー側となるための ODBC ドライバが存在しないため、桐以外のクライアントから間接的なデータ参照もデータ操作も不可能です。では、クライアントも桐ならば…… その場合、サーバー側とクライアント側の双方の桐で、 ODBCに相当する一括処理を開発者が一から構築する必要があります（もちろん、サーバー側は当該一括処理を常時稼働させておく必要があります）。桐は「クライアント＝サーバー」を実現するためのコマンドや仕組みを用意していないからです。では、たとえソレを一括処理で可能にしたとして、サーバー側の桐で TBL の排他制御を行なうのに、ファイルサイズ・レスポンス・信頼性（TBL が破壊されないように）等にどれほどの仕様要求に対する満足度が得られるでしょうか？個人や小さな事業所レベルでちょっとしたものならば充分満足がいくかもしれませんが、システムが巨大化するほど・信頼性の要求度が高いほど、桐では過重荷になりそうですが。
28875	Re:「クライアント＝サーバー」タイプのＤＢシステム	Ogo	2005/02/01-11:09
記事番号28874へのコメントクライアントとして ○「カスタマイズも皆無といっていいほどできません。」　通常、システムを開発するのに、最も神経を使うのは　「開発者が意図しない事が発生したら困る」です。　従って、桐で開発をするにしても、業者が開発するならば　「意図して用意された操作以外の事ができないようにする　には如何にすべきか」が重要事項としてリストアップされるはずです。　自前で開発するならばその辺りをできるだけルーズにして　「何でもできる」状態にするのが都合が良いですが、それ　でも不特定多数の人がいじるシステムでは、この辺りの　落とし所は難しい判断を迫られます。　開発者が「意図的に柔軟性を殺している」可能性をも考慮　して下さい（これは桐でシステム開発しても同じです）。 ○「アクセスで作られていて」　ODBC 接続によるクライアントとしての能力としては、多分、　アクセスの方に分があるでしょう（開発業者が桐と比較　してアクセスを採用しているとは思えないが）。　桐の ODBC 接続（外部接続）は重要なシステム開発レベル　で充分実用になるとは私には思えませんでした。　制限が多過ぎ、また不可解な事もあったりで、桐のみで　閉じているシステムで享受できるメリットが充分に活かさ　れる状況にはとてもなりませんでした。　ただし、フォームやレポート・一括処理の作成には桐の　メリットは充分に出て来るでしょう。イベントに関しては　怪しくなると思いますが。 ○ 桐には配布可能なランタイムバージョンがない。　アクセスなどは、開発者が配布可能なランタイムバージョン　（開発者が作成したプログラムの中でだけ、開発者の意図　通りにだけ動作して、汎用的処理には使えない限定的動作　バージョン）があります。もちろん、開発者がランタイム　バージョンを配布する権利を別途まとめ買いしていることに　なるわけですが。　桐のランタイムに関しては何度も何度も繰り返し要望が　出ているはずですが、今までに出て来たことはありません。　ちょっと考えてみて下さい。　アクセスで組んであるプログラムを使うために、ユーザーが　必ずアクセスというソフトを別途購入して（しかもアクセス　のバージョン間の互換性や異バージョンの共存の問題もある）、　事前にインストールが必要だという条件ならば、アクセスを　ＤＢエンジンとして使ったプログラムがこれほど普及してい　たでしょうか？　この件に関しては、桐は全く足下にも及びません。
28876	Re:「クライアント＝サーバー」タイプのＤＢシステム	Ogo	2005/02/01-11:24
記事番号28875へのコメント最後のまとめ「莫大な費用を投じて、不便で使いづらいシステムが導入されるのに納得がいきません。」自前でシステムを開発したらどの程度の費用になるかを見積もってみれば判断の材料になるとは思います（必ずしも桐が劣っているとは限らない）。しかし、自前の開発や自前のシステム保守が面倒だったり自信が無かったり費用対効果が劣ると思われるからこその外部委託であったりパッケージ購入であるはずです。なお外部委託であろうとも、システム構築を自前で行なうには大変な労力と時間、そして処理全般にわたる詳細な知識の集積が必要です。通常業務をこなす一方で、このようなシステム構築を同時進行できるのはかなり余力を持った事業所に限られるのではないかと思いますが。
28877	Re:桐 for TSE	Ogo	2005/02/01-11:36
記事番号28871へのコメントオマケです。「クライアント＝サーバー」システムでなくとも「桐 for TSE」というバージョンの桐を使えば疑似的に「クライアント＝サーバー」のような動作をさせることは可能です。 http://www.kthree.co.jp/2seihin/1kiri9/6terminalservice/index.html もちろん、これは「サーバーも桐」というモデルになります。当然、オラクル部分も含めて、全てのシステムを桐で自前再構築する前提ですね。 # 導入決定から運用開始までの時間的見積もりも # 極めて重要ですのでお忘れなく。
28879	Re:桐とオラクル	肥田	2005/02/01-13:19
記事番号28859へのコメント皆様、妙な質問に大変詳しいご教授ありがとうございます。以前の書き込みにもあったように桐はデスクトップツールとして使用すべきと言う事でしょうか。長年桐を愛用していて（っといっても使いこなしているのは僅かでしょうが…）パッケージシステムを操作すると、どこかもどかしさを感じて質問させていただきました。沢山の活用したいデータが目の前にあって、桐で加工や操作できない悔しさを日々感じています。利用できそうなアクセス部分に目を向けて、検討したいと思います。でも、ＯＤＢＣでつなぐことも、なかなか許してもらえないんだよなぁ～（；_；）しかし、皆さんのご意見をお伺いして小規模なら不可能ではないと感じました。（堅牢性、安定性、セキュリティetcをもちろん考慮して）また、たとえ大規模であっても小規模の集まりとも考えられるので、小規模にあたる部署をアクセス部分としてとらえ、うまく桐を利用することも有りかなと感じました。ホントにありがとうございます。
28880	Re:桐とオラクル	Ogo	2005/02/01-14:28
記事番号28879へのコメント >でも、ＯＤＢＣでつなぐことも、なかなか許してもらえないんだよなぁ～当然だと思います。桐でアクセスのデータを活用しようとするなら（システム上、それが許されるとの前提があって初めて可能ですが）、基本的には一方通行のみ（もちろんアクセス → 桐）で考えるべきでしょうし、そうでなければ周囲を説得することは難しいと思います。業務用パッケージソフトのデータの中身を ODBC で直接書き換える・データ更新する等は厳禁です。それをした場合、異常やトラブルが発生した場合でも、まず発売元・開発元のサポートは打ち切られると考えておいて下さい。 # ODBC でデータを取り出しただけでも、事前の了解が無ければ、後 # で抜き差しならない契約的信義的人間的トラブルが発生する可能性 # はあります（あくまでも「可能性」です）。
28882	Re:桐とオラクル	ぱんぱーす	2005/02/01-20:30
記事番号28880へのコメント ># ODBC でデータを取り出しただけでも、事前の了解が無ければ、後 ># で抜き差しならない契約的信義的人間的トラブルが発生する可能性 ># はあります（あくまでも「可能性」です）。個人情報保護法なんてのもできたようですし。
28946	桐利用の事例	MIT	2005/02/06-11:39
記事番号28859へのコメント肥田さん肥田さんの職場に導入されたシステムと構成が比較的近いと思われるシステムで桐を使っている事例を紹介します。元々桐で作成されたシステムがあったですが、データ量、クライアント数共に桐で扱うには無理が生じてきたた為、ＳＱＬサーバー＋クライアント側はアクセスで再構築しました。このシステムはオーダーメイドなので日常業務での使い勝手に関する不満は特にあがっていません。しかし、桐の表形式による検索操作がやりたいとのユーザー希望により特定のテーブル（顧客情報）は桐で検索などが出来るようにしました。方法は・外部ＤＢ設定で特定のテーブルを読み込み（ＯＤＢＣ接続）・読み込まれた表を共有設定されたフォルダに書き出し・各クライアントより書き出された表を共有参照で開く以上の手順を全て一括処理で行っています。読み込みは毎営業時間前に管理者の方にお願いしています。従って桐で参照できるのは最新データではありませんが、桐でデータ参照したい理由が、漠然とデータを検索したい・・具体的には、何らかの入力ミスを見つけるといった用途のため運用上は問題ないようです。漠然とした検索を一般ユーザーの方が行うのにＳＱＬ文の発行は敷居が高く危険も伴いますし、なによりそれまで桐を使っていたユーザーが何人かおられる職場だったので桐の表形式による検索は自然の成り行きかも知れません。この桐テーブルは一括処理より起動して絞り込み、検索、並べ替えが出来る程度に機能を絞って使うようにしてあります。また、ユーザーが共有参照する桐の表自体は簡単に複写できないようにするなど一応の情報漏えい防止は工夫しました。ところで、紹介したシステムではデータ接続にＯＬＥＤＢプロバイダを使っています。ＯＤＢＣで接続した場合に比べてサーバー負荷が小さくなるようです。ところが桐はＯＤＢＣ接続しかありませんので先に説明したように営業時間前に行って負荷が影響しないような運用としています。以上、桐の利用事例として御参考まで。MIT

戻る