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


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

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

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

回答の条件
  • 1人50回まで
  • 登録:2006/10/30 18:14:30
  • 終了:2006/10/31 18:54:02

ベストアンサー

id:maq No.3

maq回答回数81ベストアンサー獲得回数52006/10/30 20:37:30

ポイント32pt

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

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

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

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

id:kanchan777

ありがとうございます。

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

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

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

2006/10/30 21:19:15

その他の回答(8件)

id:b-wind No.1

b-wind回答回数3344ベストアンサー獲得回数4402006/10/30 19:26:12

ポイント16pt

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

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

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

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


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


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

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

id:kanchan777

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

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

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

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

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

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

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

2006/10/30 19:57:23
id:samasuya No.2

samasuya回答回数315ベストアンサー獲得回数112006/10/30 19:45:44

ポイント16pt

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

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

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

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


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

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

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


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

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

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

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

持たせてもいいかと。

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

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

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



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

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

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

以上です。

id:kanchan777

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

>

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

>

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

なのですかね?

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

2006/10/30 20:02:31
id:maq No.3

maq回答回数81ベストアンサー獲得回数52006/10/30 20:37:30ここでベストアンサー

ポイント32pt

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

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

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

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

id:kanchan777

ありがとうございます。

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

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

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

2006/10/30 21:19:15
id:kurukuru-neko No.4

kurukuru-neko回答回数1844ベストアンサー獲得回数1552006/10/30 20:53:12

ポイント16pt

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

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

>アプリケーションサーバが複数+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:障害などの発生時問題判別がしにくい。

id:kanchan777

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

メンテ困難とか…。

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

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

2006/10/30 21:21:26
id:kuippa No.5

くいっぱ回答回数1030ベストアンサー獲得回数132006/10/31 02:15:54

ポイント16pt

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

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

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

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

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


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

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

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


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


これは…

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

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

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

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

id:kanchan777

> 不慣れな人は本当に不慣れですし、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 を苦にするということで、出来ないのです。

2006/10/31 12:16:40
id:kurukuru-neko No.6

kurukuru-neko回答回数1844ベストアンサー獲得回数1552006/10/31 09:50:41

ポイント16pt

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

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

数年してなんらかの問題があった場合

どうでしょうか?

問題を解決するには、SPを書き換える

ような処理が必要かもしれません。

でもシステムは動作しています。

動作しているDB側の設定変更は

あまり好まれません。

Java+Oracle+SPの理解

出来る技術者が解析に必要となります。

id:kanchan777

DBを単なるストレージとして、テーブルごとにクラスを作っているようなプロジェクトでは、テーブルレイアウトの変更以外、すべてがJavaの修正で済むかもしれません。

しかし、その構造では業務システムではまっとうなパフォーマンスが出せるか疑問です。

集計などでSQLを併用していたら、Java+Oracle+SPの理解は当然必要かと。


SPを書き換えるのが嫌というのは、文化の問題で、Javaを置き換えるのとそれほど差があるとは思えないのですが。

2006/10/31 10:29:15
id:kurukuru-neko No.7

kurukuru-neko回答回数1844ベストアンサー獲得回数1552006/10/31 11:44:20

ポイント16pt

>パフォーマンスが出せるか疑問です。

業務システムでSPをほとんど使わないでも

特には問題にならない業務は多数あります。

目標性能に達しない事はSP/Java

何れで実装しても発生します。

当然設計段階で、SPにすべきものは

SPを使うべきだし。Javaでよいものは

Java側で実装するのが妥当です。

SPを使う根拠としてパフォーマンスのみを

議論をしても仕方がないと思います。

SPを使うべき場合の、設計方針・ガイド

ラインを策定し、粛々と開発するのが

妥協点と思います。

例:

 ・DB/Java間の通信量(データ)

 ・実行時間

 ・共通機能

>SPを書き換えるのが嫌というのは、

>文化の問題で、

文化の問題は非常に重要です。

最悪だと新規追加か削除しか認めら

れません。

大規模になればなるほど最終的に

実環境でしか問題判別が出来ない状況

になります、セキュリティー管理・

Oracle管理が運用側の管理下

である傾向があります。

>Java+Oracle+SPの理解は

>当然必要かと

単純に技術者の¥の問題です。

id:kanchan777

非常に大規模なので、Javaを書き換えるのも、DBを書き換えるのも、いずれも大問題で差はありません。

比較的簡単に変えれるのはCSSぐらいかな。

へたくそなプロジェクトで恥ずかしいのですが、Javaで動的なSQLを書いているのは私の感覚では見にくく、Javaの方が保守性が高いという社内の主張には納得できません。

JavaからのDBインターフェースが、静的なSQLで済むぐらいなら、SPにする必要も感じないのですが、動的なSQLになるなら、SPオンリーにしたいというのが私の考えです。


SQLは難しい、SPはなおさら難しい。

というのは、感覚としては判るのですが、乗り越えられない壁とは思えないのですが…。

2006/10/31 12:14:39
id:kurukuru-neko No.8

kurukuru-neko回答回数1844ベストアンサー獲得回数1552006/10/31 12:26:39

ポイント16pt

>非常に大規模なので、Javaを書き換える

>のも、DBを書き換えるのも、いずれも

>大問題で差はありません。

>保守性が高い

おそらくこれがJava派の理由に見えます。

規模が大きく関係者が増えれば増えるだけ

お伺いをたてる機会が増えます。

これ以上範囲を広げて面倒には巻き込ま

れたくないこれが本音のように思えます。

不審火がくすぶってきな臭い

危険な香りがしてきます。

id:kanchan777

SPはお伺いが必要で、Javaは必要ないというプロジェクトならそうかもしれませんね。

全てSPというプロジェクトであれば、Javaを直すのと、SPを直すのは等価だと思います。

JavaにSQLを書いてよいプロジェクトは、SQLでどこまで処理をさせるかによって、ビジネスロジックがSQLとJavaに分散するのは問題だと思います。

Joinを禁止しているプロジェクトもあるし、Group Byを禁止しているプロジェクトもある。

それで、パフォーマンスがでればよいけれど、普通は使用に耐えないと思う。

Group By まで書くと、その先、どこまでのロジックをSQLで表現するか微妙な線になると思います。

Group By まで書いた 動的なSQL が存在するJavaの保守性は高くないと思うのが私の意見です。

2006/10/31 13:49:25
id:firesteed No.9

firesteed回答回数7ベストアンサー獲得回数02006/10/31 12:46:15

ポイント16pt

以前に何百本もあるSPを全部DBのバージョンアップの為に当初の仕様の通り動作するか確認したことがあります。

Oracle8から9iだったと記憶していますが、、SPの内部的な動作がDBのバージョンで変わることもありえますし、特殊なpackageはバージョンアップで使えなくなることもありえます。

「そんなあやういSPを作ってるからチェックしなおさなきゃいけないんだ。」と言われれば言い返すことはできませんが、プロジェクトメンバー全員、はたまた、外注から納入されて、テスト結果が仕様に合ったものなら、細かいところまでは見きれませんよね。

SPにした場合のメリットもたくさんありますので、どちらにしたほうが良いのかは一概には言えないとは思いますが、こういった経験をした者もいる、ということで。

JAVAでほとんど同様のSQL文字列を作って実行するのだったらそれはJAVAである必要は無いと思いますけど。

id:kanchan777

8iから9iは経験がありますが、8から9iは大変だったのでしょうか?

ストアドならクロスリファレンスを作ったりも簡単に出来て、問題となるPackageはリリースノートにあると思いますが…。

確かに問題が起きるかもしれませんが、どんな言語でも起きる問題で、SPだから防げなくて、Javaだから防げるという問題でもないと思います。

むしろ、OracleのSPは被害が少ない気がします。

もちろん、Oracle → SQLServer の可能性が見えているプロジェクトなら、SQLの構文にまでこだわるべきで、SPの問題じゃないですよね。

2006/10/31 13:01:10
  • id:kuippa
    もっと平たいことを言うとプロジェクトの規模がDB選任チームをつくれるのか?というところに帰結するんじゃないですかね。
    各機能単位でメンバーの割り振りをするのであれば担当者が情報の抽出を含めた画面周りまでつくりこまなきゃいけないし。
    10~15人ぐらいの規模のJOBじゃDB選任担当者を設けるのは全体的な効率低下に繋がるような気がします。
    ほんとうにクリティカルな部分だけでマルチに立ち回れる立場の人がSPにするレベルでいいじゃないでしょうか。
    逆に20人以上常時いるような規模であれば、そういう効率化を求めるのはありないのかなと。
    10人ぐらいの規模で全員にDBを操作させてしまうのは設計やマネジメントとしてどうなの、と思ってしまいます。
  • id:kanchan777
    おっしゃるとおりで。

    実は100人規模です。

    基本的にCOBOLerばかりで、テーブル設計もなってない。
    全体に能力不足なのは否めません(笑)

    少数精鋭でロジック部門を作ってくれればと。
    経験の浅い技術者がよってたかって、JavaにSQLをベタ書きされたら…。

    私は Java と SQL は真逆のスキルだと思うので分離したいんです。
    でなければ、Joinすら禁止して、DBはストレージとして使うかですね。

  • id:b-wind
    いろんな前提上限があったようで自分の回答は的外れになってしまったようです。

    実際問題 id:kanchan777 さんが見てストアドをメンテできる人員はどの程度居るんでしょうか?
    最終的にストアドで作成し、プロジェクトを終了できたとしてその後のフォローは大丈夫なんでしょうか?
    自分は自分しか扱えないシステムを抱えてしまい苦労しました。
    プロジェクトの成否以前にそういうところを心配してしまいます。
  • id:kanchan777
    ありがとうございます。
    社内の抵抗感がどれぐらい一般的なのか質問したかったわけです。

    PGレベルは問題ないのです。
    ただし、レビュアーがCOBOLerということが問題かな。

    行レベルの処理しか認めない。
    その人がコーディングまでレビューすることはないのですが…。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません