人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

JavaとOracleを使って業務システムを開発しています。

ビジネスロジックをどこに持ってくるか悩んでいます。
ストアドプロシージャにビジネスロジックを実装した方がパフォーマンスもよくなると思うのですが、社内的には反対意見も多いです。

ストアドプロシージャにビジネスロジックことがある方、検討したことがある方、利点や弊害など教えてください。

逆にJava側に乗せた方がよいという方も、ご意見頂戴できればありがたいです。


●質問者: kanchan777
●カテゴリ:コンピュータ 科学・統計資料
✍キーワード:Java Oracle システム パフォーマンス ビジネスロジック
○ 状態 :終了
└ 回答数 : 9/9件

▽最新の回答へ

1 ● b-wind
●16ポイント

ありがちな回答ですが、ストアドプロシージャーの方が必ずパフォーマンスが上がる訳ではありません。

CPU負荷が高い環境だと処理をアプリケーションサーバーに持ってきた方が、効率がよい場合も考えられます。

実際にパフォーマンスの上がるパターンでは有効な手段ですが。

自分の経験では Web 系なので、ストアドで処理した方が有効なパターンはありませんでした。ごくシンプルなクエリばかりですから。


Java 以外のアプリケーションからのアクセスがある場合、ストアドでDBにロジックを持ってくるとロジックの共通化が出来るというメリットはあります。


どちらかというと実際開発・メンテナンスする人間がどの程度使えるかを重視した方がよいかと思います。

メンテナンスできる人間が運用時にはいないとなるとそもそも運用に耐えられない危険性もあります。

◎質問者からの返答

確かに、Web系では単純ですからテーブル毎にクラスを作ったりした方が保守性もよいかもしれません。

今回の案件は、アプリケーションサーバが複数+DB×2台という規模で、複雑な集計処理も多いです。

パフォーマンス的にはストアドプロシージャの方が速いのは間違いありません。

社内のストアドプロシージャは難しいという拒否感を、パフォーマンスを理由に乗り越えさせる方がよいのか、無理しない方がよいのか悩んでいます。

担当者の能力に拠ってハードルの高さは違いますが、ストアドプロシージャでやったら失敗する。

とか、パフォーマンス以外にも、ストアドプロシージャの方がメリットがある。

ということがありましたら、教えてください。


2 ● samasuya
●16ポイント

>JavaとOracleを使って業務システム

というのがどういう形態なのかわからないので

なんともいえませんが、ストアドプロシージャーの難点について

ご回答させていただきます。


規模がわからないので、逆にパフォーマンスがよくなるかも

しれませんが、DBサーバーのスペックを大きくしておかないと、

同時接続時の処理が遅くなると思われます。


webでの提供だと、Java側に持っているとスペック不足に

なった場合、web、アプリケーションサーバーの増強で対応できますが、ストアドプロシージャーだとDBサーバーの増強になります。

C/S形態でも、Java Web Startという機能を使えば

最新版を起動時に使えるようになるので、Java側にロジックを

持たせてもいいかと。

あとストアドより、データをJava側の機能を使って

処理するほうが楽な気がしますね。

配列とか、その辺、Javaの方がだいぶ楽だった記憶があります。



3階層のwebシステムの考え方に思いっきり拠ってますが、

考え方としてDBは、データの保持、アプリは、ビジネスロジック、

インターフェースの提供というのがスタンダードだと思います。

以上です。

◎質問者からの返答

> あとストアドより、データをJava側の機能を使って

>

> 処理するほうが楽な気がしますね。

>

> 配列とか、その辺、Javaの方がだいぶ楽だった記憶があります。

なのですかね?

結局、DBに対するアクセスはSQLを使うのであれば、ストアドプロシージャでも同じような気もしますが。


3 ● maq
●32ポイント ベストアンサー

個人的には、トレードオフの問題ではないかと思っているのですが…。

あの、Martin Fowler氏の以下の文章が結構興味深かったです。

「ドメインロジックとSQL」

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

◎質問者からの返答

ありがとうございます。

Martin Fowler氏のサンプルを見ると、比べるまでもなく圧倒的にSQLが簡単に見えますし、ほかの方法は私には苦行です。

その上20倍もパフォーマンスが違ったら、私はどうしてもSQLを選びますが、世の中の人は違うのですね。

「HAVING ってなに?」という人は私は技術者と認めないけど…。


4 ● kurukuru-neko
●16ポイント

>ストアドプロシージャに・・

>利点や弊害など教えてください

>アプリケーションサーバが複数+DB×2台という規模

3階であればSPにビジネスロジックを限定するのは

好ましくないと思います。

実行時間が遅いことが事前に予測で可能な状態であれば

限定してその部分のチューニングを行う目的で

該当部分に限定してSPを使うことも検討にする価値は

あるとは思います。

1:ビジネスロジックがDB操作で完結するとは限らない。

外部との連携や、DB以外の処理もありえる。

2:並列・平行・順次処理など複雑なビジネス

ロックが必要な場合、SPで実現困難

3:大規模なSPはメンテ困難

4:繰り返し同じような処理をしたり

内部処理を隠蔽したいような目的には使いやすい。

5:SPでも早くなるとは限らない。

(覚えるのが面倒なのも理由のひとつ)

6:Javaストアド・プロシージャ

http://otn.oracle.co.jp/tech/java/jsp/

7:障害などの発生時問題判別がしにくい。

◎質問者からの返答

やっぱり、みんなSQLが嫌いなんですね。

メンテ困難とか…。

> 7:障害などの発生時問題判別がしにくい。

というのは、具体的にどんなときでしょう?


5 ● くいっぱ
●16ポイント

ものによるかと思いますが充分ありですよ。

ほぼストアドなシステムもあります。

要は扱うものの内容次第ではないですか?

数字を扱ってそれが集計や分析が入るのであればおのずとコアはストアドで組んだ方が効率が出ます。集計がUIと非同期になるようなものの場合クライアント側に処理を集結させてしまうほうが問題かと思います。

逆にクライアント側でのSQLで済むようなものに対して、ストアドをわざわざつくってDB側に隠蔽するのはやりすぎだと思います。ブラックボックスにしたいのであれば別ですが・・・


> アプリケーションサーバが複数+DB×2台という規模で、複雑な集計処理も多いです。

> パフォーマンス的にはストアドプロシージャの方が速いのは間違いありません。

例えば、極端な例ですがアプリケーションサーバで処理すると一昼夜掛けても終わらなかったような処理もストアドなら10分でできたりしますよね。これくらいならやる価値はあるというか、そんな組み方するな!というところですが、2秒の処理が1秒になったというような細かいところで追求するべきではないと思います。


> 社内のストアドプロシージャは難しいという拒否感を、パフォーマンスを理由に乗り越えさせる方がよいのか、無理しない方がよいのか悩んでいます。


これは…

正直、自分しかできる人が居ないのであれば「自分がケツを持つ」という覚悟が無い限り諦めたほうがいいのでは…

難しいという苦手意識がある以上、実際難しいのでしょう。

今回はボトルネックになりそうな部分だけとか、そういう譲歩をしながら技術を共有していかないと、いきなりの前面宗旨替えは無理があります。

不慣れな人は本当に不慣れですし、SQLの場合どうにもなりません。メンテ困難というよりは作成物のデータの正当性を検証するのはソースレビューなどで一見で確認しただけでは担保できないという事です。

◎質問者からの返答

> 不慣れな人は本当に不慣れですし、SQLの場合どうにもなりません。


なのですね。



ブラックボックスにしたいというのは個人的な理想です。

Javaを使ったWebシステムであれば、

・デザイン

・UI

・ビジネスロジック

・DB設計

…とまったく違う技術の組み合わせですが、現状のプロジェクトでは機能単位で割振ってウォータフォールでやってます。

(下請けなんでね)


デザインなど、まったく出来ない人が、客先でデザインの打合せと、ビジネスロジックの打合せを並行に進めるというのは、無理があるに決まっています。

UIまでは、プロトタイピングの方が向いていて、ビジネスロジックはウォータフォールが向いている。

ビジネスロジックをSPにして、Oracleなら

SELECT 1 AS ID , '顧客名xxxxx01' AS CNAME FROM DUAL

UNION (ALL)

SELECT 2 AS ID , '顧客名xxxxx02' AS CNAME FROM DUAL

・・・

というような内容を返すSPを作ってやればスタブ開発ができるはず。

UNION を使うスタブSQLは、エクセルで簡単なツールが作れて、そのエクセルはJava ⇔ SPのインターフェース仕様書+サンプルになる。

ビジネスロジックは、UIをのけた部分で、インターフェース仕様書を見ながらじっくりウォータフォールで進める。

これなら、手戻りを最小限に抑えられ、それぞれ得意分野で活躍してもらえるプロジェクトになる(ならない?)


ビジネスロジックが固まらないので、フレームワークを使ってもJavaが進まない。

テーブル変更が一番の手戻りになる。

ユーザは先ず動きを見たがる。

などなど、トラブルの要因はかなりつぶせると思います。

見積もりなんて、全部ウォータフォールでやるよりも、正確なものが出るような…。


COBOLチックなドキュメントと、進捗管理が好きな人には理解できないかもしれませんが、ひとつの理想です。

もうひとつの障害が、ビジネスロジックを作る人が SP を苦にするということで、出来ないのです。


1-5件表示/9件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ