ビジネスロジックをどこに持ってくるか悩んでいます。
ストアドプロシージャにビジネスロジックを実装した方がパフォーマンスもよくなると思うのですが、社内的には反対意見も多いです。
ストアドプロシージャにビジネスロジックことがある方、検討したことがある方、利点や弊害など教えてください。
逆にJava側に乗せた方がよいという方も、ご意見頂戴できればありがたいです。
No.3
81
5
32pt
個人的には、トレードオフの問題ではないかと思っているのですが…。
あの、Martin Fowler氏の以下の文章が結構興味深かったです。
「ドメインロジックとSQL」
No.1
3344440
16pt
ありがちな回答ですが、ストアドプロシージャーの方が必ずパフォーマンスが上がる訳ではありません。
CPU負荷が高い環境だと処理をアプリケーションサーバーに持ってきた方が、効率がよい場合も考えられます。
実際にパフォーマンスの上がるパターンでは有効な手段ですが。
自分の経験では Web 系なので、ストアドで処理した方が有効なパターンはありませんでした。ごくシンプルなクエリばかりですから。
Java 以外のアプリケーションからのアクセスがある場合、ストアドでDBにロジックを持ってくるとロジックの共通化が出来るというメリットはあります。
どちらかというと実際開発・メンテナンスする人間がどの程度使えるかを重視した方がよいかと思います。
メンテナンスできる人間が運用時にはいないとなるとそもそも運用に耐えられない危険性もあります。
確かに、Web系では単純ですからテーブル毎にクラスを作ったりした方が保守性もよいかもしれません。
今回の案件は、アプリケーションサーバが複数＋DB×２台という規模で、複雑な集計処理も多いです。
パフォーマンス的にはストアドプロシージャの方が速いのは間違いありません。
社内のストアドプロシージャは難しいという拒否感を、パフォーマンスを理由に乗り越えさせる方がよいのか、無理しない方がよいのか悩んでいます。
担当者の能力に拠ってハードルの高さは違いますが、ストアドプロシージャでやったら失敗する。
とか、パフォーマンス以外にも、ストアドプロシージャの方がメリットがある。
ということがありましたら、教えてください。
No.2
31511
16pt
>JavaとOracleを使って業務システム
というのがどういう形態なのかわからないので
なんともいえませんが、ストアドプロシージャーの難点について
ご回答させていただきます。
規模がわからないので、逆にパフォーマンスがよくなるかも
しれませんが、DBサーバーのスペックを大きくしておかないと、
同時接続時の処理が遅くなると思われます。
webでの提供だと、Java側に持っているとスペック不足に
なった場合、web、アプリケーションサーバーの増強で対応できますが、ストアドプロシージャーだとDBサーバーの増強になります。
C/S形態でも、Java Web Startという機能を使えば
最新版を起動時に使えるようになるので、Java側にロジックを
持たせてもいいかと。
あとストアドより、データをJava側の機能を使って
処理するほうが楽な気がしますね。
配列とか、その辺、Javaの方がだいぶ楽だった記憶があります。
３階層のwebシステムの考え方に思いっきり拠ってますが、
考え方としてDBは、データの保持、アプリは、ビジネスロジック、
インターフェースの提供というのがスタンダードだと思います。
以上です。
> あとストアドより、データをJava側の機能を使って
>
> 処理するほうが楽な気がしますね。
>
> 配列とか、その辺、Javaの方がだいぶ楽だった記憶があります。
なのですかね？
結局、DBに対するアクセスはSQLを使うのであれば、ストアドプロシージャでも同じような気もしますが。
No.3
815
ここでベストアンサー
32pt
個人的には、トレードオフの問題ではないかと思っているのですが…。
あの、Martin Fowler氏の以下の文章が結構興味深かったです。
「ドメインロジックとSQL」
ありがとうございます。
Martin Fowler氏のサンプルを見ると、比べるまでもなく圧倒的にＳＱＬが簡単に見えますし、ほかの方法は私には苦行です。
その上２０倍もパフォーマンスが違ったら、私はどうしてもＳＱＬを選びますが、世の中の人は違うのですね。
「HAVING ってなに？」という人は私は技術者と認めないけど…。
No.4
1844155
16pt
>ストアドプロシージャに・・
>利点や弊害など教えてください
>アプリケーションサーバが複数＋DB×２台という規模
３階であればSPにビジネスロジックを限定するのは
好ましくないと思います。
実行時間が遅いことが事前に予測で可能な状態であれば
限定してその部分のチューニングを行う目的で
該当部分に限定してSPを使うことも検討にする価値は
あるとは思います。
１：ビジネスロジックがＤＢ操作で完結するとは限らない。
外部との連携や、ＤＢ以外の処理もありえる。
２：並列・平行・順次処理など複雑なビジネス
ロックが必要な場合、SPで実現困難
３：大規模なSPはメンテ困難
４：繰り返し同じような処理をしたり
内部処理を隠蔽したいような目的には使いやすい。
５：SPでも早くなるとは限らない。
（覚えるのが面倒なのも理由のひとつ）
６：Javaストアド・プロシージャ
http://otn.oracle.co.jp/tech/java/jsp/
７：障害などの発生時問題判別がしにくい。
やっぱり、みんなＳＱＬが嫌いなんですね。
メンテ困難とか…。
> ７：障害などの発生時問題判別がしにくい。
というのは、具体的にどんなときでしょう？
No.5
103013
16pt
ものによるかと思いますが充分ありですよ。
ほぼストアドなシステムもあります。
要は扱うものの内容次第ではないですか？
数字を扱ってそれが集計や分析が入るのであればおのずとコアはストアドで組んだ方が効率が出ます。集計がUIと非同期になるようなものの場合クライアント側に処理を集結させてしまうほうが問題かと思います。
逆にクライアント側でのSQLで済むようなものに対して、ストアドをわざわざつくってDB側に隠蔽するのはやりすぎだと思います。ブラックボックスにしたいのであれば別ですが・・・
> アプリケーションサーバが複数＋DB×２台という規模で、複雑な集計処理も多いです。
> パフォーマンス的にはストアドプロシージャの方が速いのは間違いありません。
例えば、極端な例ですがアプリケーションサーバで処理すると一昼夜掛けても終わらなかったような処理もストアドなら１０分でできたりしますよね。これくらいならやる価値はあるというか、そんな組み方するな！というところですが、２秒の処理が１秒になったというような細かいところで追求するべきではないと思います。
> 社内のストアドプロシージャは難しいという拒否感を、パフォーマンスを理由に乗り越えさせる方がよいのか、無理しない方がよいのか悩んでいます。
これは…
正直、自分しかできる人が居ないのであれば「自分がケツを持つ」という覚悟が無い限り諦めたほうがいいのでは…
難しいという苦手意識がある以上、実際難しいのでしょう。
今回はボトルネックになりそうな部分だけとか、そういう譲歩をしながら技術を共有していかないと、いきなりの前面宗旨替えは無理があります。
不慣れな人は本当に不慣れですし、SQLの場合どうにもなりません。メンテ困難というよりは作成物のデータの正当性を検証するのはソースレビューなどで一見で確認しただけでは担保できないという事です。
> 不慣れな人は本当に不慣れですし、SQLの場合どうにもなりません。
なのですね。
ブラックボックスにしたいというのは個人的な理想です。
Javaを使ったWebシステムであれば、
・デザイン
・UI
・ビジネスロジック
・ＤＢ設計
…とまったく違う技術の組み合わせですが、現状のプロジェクトでは機能単位で割振ってウォータフォールでやってます。
（下請けなんでね）
デザインなど、まったく出来ない人が、客先でデザインの打合せと、ビジネスロジックの打合せを並行に進めるというのは、無理があるに決まっています。
UIまでは、プロトタイピングの方が向いていて、ビジネスロジックはウォータフォールが向いている。
ビジネスロジックをSPにして、Oracleなら
SELECT 1 AS ID , '顧客名ｘｘｘｘｘ０１' AS CNAME FROM DUAL
UNION (ALL)
SELECT 2 AS ID , '顧客名ｘｘｘｘｘ０２' AS CNAME FROM DUAL
・・・
というような内容を返すSPを作ってやればスタブ開発ができるはず。
UNION を使うスタブSQLは、エクセルで簡単なツールが作れて、そのエクセルはJava ⇔ SPのインターフェース仕様書＋サンプルになる。
ビジネスロジックは、UIをのけた部分で、インターフェース仕様書を見ながらじっくりウォータフォールで進める。
これなら、手戻りを最小限に抑えられ、それぞれ得意分野で活躍してもらえるプロジェクトになる（ならない？）
ビジネスロジックが固まらないので、フレームワークを使ってもJavaが進まない。
テーブル変更が一番の手戻りになる。
ユーザは先ず動きを見たがる。
などなど、トラブルの要因はかなりつぶせると思います。
見積もりなんて、全部ウォータフォールでやるよりも、正確なものが出るような…。
COBOLチックなドキュメントと、進捗管理が好きな人には理解できないかもしれませんが、ひとつの理想です。
もうひとつの障害が、ビジネスロジックを作る人が SP を苦にするということで、出来ないのです。
No.6
1844155
16pt
>> ７：障害などの発生時問題判別がしにくい。
>>というのは、具体的にどんなときでしょう？
数年してなんらかの問題があった場合
どうでしょうか？
問題を解決するには、ＳＰを書き換える
ような処理が必要かもしれません。
でもシステムは動作しています。
動作しているＤＢ側の設定変更は
あまり好まれません。
Ｊａｖａ＋Ｏｒａｃｌｅ＋ＳＰの理解
出来る技術者が解析に必要となります。
ＤＢを単なるストレージとして、テーブルごとにクラスを作っているようなプロジェクトでは、テーブルレイアウトの変更以外、すべてがJavaの修正で済むかもしれません。
しかし、その構造では業務システムではまっとうなパフォーマンスが出せるか疑問です。
集計などでSQLを併用していたら、Ｊａｖａ＋Ｏｒａｃｌｅ＋ＳＰの理解は当然必要かと。
ＳＰを書き換えるのが嫌というのは、文化の問題で、Javaを置き換えるのとそれほど差があるとは思えないのですが。
No.7
1844155
16pt
＞パフォーマンスが出せるか疑問です。
業務システムでＳＰをほとんど使わないでも
特には問題にならない業務は多数あります。
目標性能に達しない事はＳＰ／Ｊａｖａ
何れで実装しても発生します。
当然設計段階で、ＳＰにすべきものは
ＳＰを使うべきだし。Ｊａｖａでよいものは
Ｊａｖａ側で実装するのが妥当です。
ＳＰを使う根拠としてパフォーマンスのみを
議論をしても仕方がないと思います。
ＳＰを使うべき場合の、設計方針・ガイド
ラインを策定し、粛々と開発するのが
妥協点と思います。
例:
・DB/Java間の通信量（データ）
・実行時間
・共通機能
>ＳＰを書き換えるのが嫌というのは、
>文化の問題で、
文化の問題は非常に重要です。
最悪だと新規追加か削除しか認めら
れません。
大規模になればなるほど最終的に
実環境でしか問題判別が出来ない状況
になります、セキュリティー管理・
Ｏｒａｃｌｅ管理が運用側の管理下
である傾向があります。
>Ｊａｖａ＋Ｏｒａｃｌｅ＋ＳＰの理解は
>当然必要かと
単純に技術者の￥の問題です。
非常に大規模なので、Javaを書き換えるのも、DBを書き換えるのも、いずれも大問題で差はありません。
比較的簡単に変えれるのはCSSぐらいかな。
へたくそなプロジェクトで恥ずかしいのですが、Javaで動的なSQLを書いているのは私の感覚では見にくく、Javaの方が保守性が高いという社内の主張には納得できません。
JavaからのDBインターフェースが、静的なSQLで済むぐらいなら、SPにする必要も感じないのですが、動的なSQLになるなら、SPオンリーにしたいというのが私の考えです。
SQLは難しい、SPはなおさら難しい。
というのは、感覚としては判るのですが、乗り越えられない壁とは思えないのですが…。
No.8
1844155
16pt
>非常に大規模なので、Javaを書き換える
>のも、DBを書き換えるのも、いずれも
>大問題で差はありません。
>保守性が高い
おそらくこれがJava派の理由に見えます。
規模が大きく関係者が増えれば増えるだけ
お伺いをたてる機会が増えます。
これ以上範囲を広げて面倒には巻き込ま
れたくないこれが本音のように思えます。
不審火がくすぶってきな臭い
危険な香りがしてきます。
SPはお伺いが必要で、Javaは必要ないというプロジェクトならそうかもしれませんね。
全てSPというプロジェクトであれば、Javaを直すのと、SPを直すのは等価だと思います。
JavaにSQLを書いてよいプロジェクトは、SQLでどこまで処理をさせるかによって、ビジネスロジックがSQLとJavaに分散するのは問題だと思います。
Joinを禁止しているプロジェクトもあるし、Group Byを禁止しているプロジェクトもある。
それで、パフォーマンスがでればよいけれど、普通は使用に耐えないと思う。
Group By まで書くと、その先、どこまでのロジックをSQLで表現するか微妙な線になると思います。
Group By まで書いた 動的なSQL が存在するJavaの保守性は高くないと思うのが私の意見です。
No.9
70
16pt
以前に何百本もあるSPを全部DBのバージョンアップの為に当初の仕様の通り動作するか確認したことがあります。
Oracle8から9iだったと記憶していますが、、SPの内部的な動作がDBのバージョンで変わることもありえますし、特殊なpackageはバージョンアップで使えなくなることもありえます。
「そんなあやういSPを作ってるからチェックしなおさなきゃいけないんだ。」と言われれば言い返すことはできませんが、プロジェクトメンバー全員、はたまた、外注から納入されて、テスト結果が仕様に合ったものなら、細かいところまでは見きれませんよね。
SPにした場合のメリットもたくさんありますので、どちらにしたほうが良いのかは一概には言えないとは思いますが、こういった経験をした者もいる、ということで。
JAVAでほとんど同様のSQL文字列を作って実行するのだったらそれはJAVAである必要は無いと思いますけど。
8iから9iは経験がありますが、8から9iは大変だったのでしょうか？
ストアドならクロスリファレンスを作ったりも簡単に出来て、問題となるPackageはリリースノートにあると思いますが…。
確かに問題が起きるかもしれませんが、どんな言語でも起きる問題で、SPだから防げなくて、Javaだから防げるという問題でもないと思います。
むしろ、OracleのSPは被害が少ない気がします。
もちろん、Oracle → SQLServer の可能性が見えているプロジェクトなら、SQLの構文にまでこだわるべきで、SPの問題じゃないですよね。
くいっぱ
2006/10/31 20:41:37
8
8
kanchan777
b-wind
3
4
2
ありがとうございます。
Martin Fowler氏のサンプルを見ると、比べるまでもなく圧倒的にＳＱＬが簡単に見えますし、ほかの方法は私には苦行です。
その上２０倍もパフォーマンスが違ったら、私はどうしてもＳＱＬを選びますが、世の中の人は違うのですね。
「HAVING ってなに？」という人は私は技術者と認めないけど…。