- - PR -
基本的な業務システムの作り方について
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2007-08-10 12:36
こんにちは。
現在、給与管理システムの開発に向けて仕様等を検討しているところなのですが、基本的な業務システムの作り方についてご意見をお聞かせいただければと思い、投稿させていただきました。 業務システムは私自身現在とは別の会社で(パッケージカスタマイズですが)開発した経験があり、そのときはVB+OracleでクライアントをVB、サーバー側の処理をPL/SQLで行ったり、VB+OracleでクライアントをVB、サーバー側をJavaとし、Javaでデータの取得を行う方法が主でした。 現在の会社ではそもそも業務システムの開発実績がほとんどなく、VB.netでDBからデータを取得、更新するのみです。 今回担当するシステムで、現在確定している段階ではVB.netとSQLServer2005で行う予定で、排他制御が必要なのですが、この場合VB.netのみでSQLの発行等行っても問題ないのでしょうか。 何分開発経験自体短く、初歩的な質問かと思いますが、ご意見をいただければと思います。よろしくお願いいたします。 | ||||
|
投稿日時: 2007-08-10 12:55
VB.netのみで? VBってのはただの言語だ。 .NETアプリケーションってのは.NET Frameworkで動いている。 VB.netというのはこいつを利用しているにすぎない。 ここまでの脳内補完があっているとすれば何も問題ないという回答になる。 | ||||
|
投稿日時: 2007-08-10 13:11
排他制御はやっかいです。DataSetによる楽観的ロックというのができますが、コミット、ロールバックのようなこともできるようです。カウンターのようなものを作って、ヘッダーテーブルと明細テーブルのシリアル番号につかいましたが、カウンターについては、排他制御が必要です。誰か.net で排他制御できるカウンターの作り方を教えていただきたいです。
| ||||
|
投稿日時: 2007-08-10 13:36
別スレッド立ててね。 | ||||
|
投稿日時: 2007-08-10 14:37
んでスレ主さんの話題に戻ると、
単に過去の経験と違うやり方をしようとする事に対して、漠然とした不安がある状態ですか? ここでは排他制御が課題にあがっていますが、方式の選定にあたっては、 ネットワークトラフィックとかレスポンスとかモジュールの配布だとか、検討すべき課題は色々あるので、疑問点を洗い出して経験のある方法と比較してみてはどうですか。 あんまり書くと脱線していきそうなので、この辺で。 | ||||
|
投稿日時: 2007-08-10 15:06
ぶさいくろうさん、yawata133さん、まるくさん、皆様早速のご返答有難うございます。
私の説明が漠然としていてご迷惑をおかけしました。(まるくさん、ありがとうございます) まるくさんのおっしゃるとおり、過去の業務システムの経験とは異なるやり方で漠然とした不安があります。 VB.net自体初めてで、入門書等ではVB.netで全てを行い、クライアントとサーバーを(DB以外では)意識しなくても出来るとは思うのですが、実務ではどうなのだろうと迷っている次第です。 過去の経験といっても、カスタマイズのレベルなので全てを理解しているわけではないのですが、販売管理でデータ数が多かったり、そもそもテーブル数が多く複数クライアントで使用することが多かったので、クライアントソフトからサーバー側にあるアプリケーションを呼び出して、データ操作する(VB側では基本的に画面制御のみ)というやり方だと排他制御を管理しやすいのかなという漠然とした印象がありました。(あと、処理的にも速度が上がるのかと) 今回、データ量やテーブルの部分はそこまで多くはないのですが、排他制御ということを考えると、VB.netではなんだか結構厄介そうなので、一業務システムではどのように考えられているのだろうと思い、質問させていただきました。 運用環境は社内LANで行う予定ですが、将来的にVPN経由で遠隔地からの使用もありえなくはないので、サーバー側でアプリケーションを持つほうが、配布が楽かなとか(ClickOnceを使えばいいのでしょうが)、比較したことがないのでわからないのですが、クライアントソフトとサーバーアプリケーションに分けた場合とそうでない場合ではどこまで差が出るものなのでしょうか。 メリットデメリットいろいろお聞かせ下さい。よろしくお願いいたします。 | ||||
|
投稿日時: 2007-08-10 15:57
さかもとと申します。
まず、「排他制御」というのは抜きにして、もしもクライアント〜DB間での処理を早くするということであればストアドプロシージャの利用は欠かせないと思います。特にいわゆる「バッチ処理」を行う必要があれば尚更です。 ただ、おっしゃっている「サーバー側のアプリケーション」という意味にストアドが当てはまるのかは分かりませんが。 _________________ ------------------------------------------ 拝啓、さかもとと申します♪ | ||||
|
投稿日時: 2007-08-11 08:15
さかもとさま、ご返答有難うございます。
私の過去やったものでは、VB+PL/SQL(Oracle)がストアドプロシージャの利用にあたると思いますので(パッケージなので余り意識していなかったんですが)、締め処理などの発生する処理には、やはりSQLServerに任せた形でストアドプロシージャの利用も必要ですね。そうなると、他の一般的な登録関係も統一するためには利用するべきなのでしょうか。 また処理速度以外にもストアドプロシージャの利便性とかデメリットとかのご経験上ありましたらお教え下さい。(私個人としては、VB.netの中にSQLがというのが違和感だったので分離できる点では見やすいのかなと思っていますが、SQLServerのストアドプロシージャの利用が皆初めてなので開発メンバーでちょっと意見が分かれております) ちなみに、ストアドプロシージャとは別にサーバー側のアプリケーション(サーバーにおいてあるプログラム)がクライアントから処理を受けてデータを渡す・・・というのはあまり一般的ではないのでしょうか。 |
1|2|3
次のページへ»