- - PR -
JAVAとストアドプロシージャの共同実装ってどうなのでしょう
1
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-10-11 21:15
始めまして、新参者のなまけものです。
# ふざけたハンドル名はご容赦を # さっきは間違って見当違いな会議室に投稿してしまいました。 # 即効削除はしましたが・・・ああボケボケ 非常に雑な質問で申し訳ないですが "JavaでWebシステムを開発する場合、ストアドプロシージャ利用しますか？" 現在当方は、Tomcat＋Oracle 9iを利用したシステムを開発中です。 Java（JSP含む）で開発をすすめており、今のところはほぼJavaオンリーで 開発しています。 が、メンバーの一人から 「ストアドプロシージャ(PL/SQL)を使ってロジックを共有したい」 との要望がでました。 私個人としては、すでに開発が進んでいる状態で開発手法を増やしたくないのが 本音ですが・・・ 処理の重点がデータの登録と検索なんで、DBの機能を利用するのも手かなあ、 とちょっと考えがふらふらしている状況です。 悩む原因はこんなところかと ・開発手法が増える。 ・管理しなくちゃいけないコードの種類が増える。 ・管理しなくちゃいけないモジュールが増える （TomcatのWebAppとOracleのPL/SQL） ・処理ロジックが分散して、JavaとPL/SQLとで重複しないか。 # Javaストアドプロシージャは・・・不勉強なのでご勘弁を 開発体制がちゃんと管理されてたら大丈夫じゃないのって言われたら・・・ 返す言葉もありません。 が、これが最初からストアドプロシージャを使うと考えていたなら、 Javaとストアドプロシージャでの役割分担を決めるなり、あらかじめ管理体制 を作っておけたかと思うので（ホントに？）、こんなに悩かったと思います。 皆様は、こんな場合どうされますか？ また、どのように管理されますか？ ご意見よろしくお願いいたします。 # 当方、明日は終日当会議室をチェックできないため音信不通となりますが # ご勘弁ください。 | ||||||||
|
投稿日時: 2002-10-12 12:11
ストアドプロシージャを使うという行為自体は全く問題ないと思います。
パフォーマンス、セキュリティ面で有利ということもあります。 また、メンテナンス性ということにおいてもストアドプロシージャが 悪影響を与えるとは考えにくいです。むしろDBアクセスのロジックを集中管理 できるメリットもあります。 ただ、DBMSに依存したくない等の要件があるのなら、 ちょっと話は変わりますね。 個人的には、ストアドプロシージャを使ったほうが有利な 場面では使ったほうがいいという意見です。 どっちかだけ、とこだわることはないと思っています。 JavaオンリーとはいってもSQLは書いてるわけでしょうし。 ちゃんとストアドプロシージャを作るときには意義を話し合う、 作ったらみんながそれを使う、 インターフェースをきちんと確認する、 というふうにきちんと共有体制ができていればいいんじゃないでしょうか。 | ||||||||
|
投稿日時: 2002-10-12 12:42
PL/SQLとJavaのロジックの二重持ちを懸念されているようですが、
そんなに心配することでもないかと思っています。amnakyさんも 指摘しておられるように、SQLとJavaの二重の言語を既に実装され ている訳ですから、「高機能なSQL」としてのPL/SQLはあっても そんなに目障りではないです。 PL/SQL自体はJavaとかぶるレベルまで高機能ではないというのが 私の感想です。 | ||||||||
|
投稿日時: 2002-10-12 18:38
なまけものさんのところは「Javaオンリー」ということなので、せっかくそれだけの技量があるなら EJBを使われるのも良いかもしれません。Oracleも使える環境のようですし。（進行中のプロジェクトへの影響次第ですが。）
私なら確かにストアドプロシージャは応答が良いので魅力ですが、DBには依存したくないですね。（レスポンスと保守性等のバランス？） それより、メンバーの意見を汲み取るのか、抑えてしまうのかといった技術以外の要素も考慮が必要ではないでしょうか。 どの場合（たとえサーブレット、JSPだけで組む）にしても、表示用のコンテンツ生成と、ビジネスロジック、DBへのアクセスを分離して少なからず発生するだろう変更要求に耐えられるようにしたほうが良いと思います。そうすれば、DBが遅いと感じた時点でそこだけをストアドプロシジャに替える途も開けるし、「ロジックを共有したい」という要望への解決につながるかも知れません。 | ||||||||
|
投稿日時: 2002-10-12 20:44
OracleのJavaストアドプロシジャの場合、DBのアクセスは、jdbcと同じ方法で行います。
もし、現在JDBCでJavaプログラムがかかれているのであれば、ほとんどそのままストアド」プロシジャに移行できます。Classファイルか、Javaソースを入れて、そのラッパのプロシジャ をPL/SQLで書く-通常は、宣言部を除けば１行-だけです。 思ったよりも簡単ですので、一度試してみてはどうでしょうか？ | ||||||||
|
投稿日時: 2002-10-14 12:12
amnaky様、こべっこ様、Kissinger様、BUBU様
ご返事ありがとうございます。（まとめレスですみませんがご了承を） amnaky様、こべっこ様 ご指摘の通り、SQL自体が言語ですでに２重実装っていわれてみればその通りですね。 > 「高機能なSQL」としてのPL/SQL そうか！ この着眼点はちょっと目からウロコでした。ありがとうございます。 > ちゃんとストアドプロシージャを作るときには意義を話し合う、 > 作ったらみんながそれを使う、 > インターフェースをきちんと確認する、 > というふうにきちんと共有体制ができていればいいんじゃないでしょうか。 うっ、耳が痛い。 私のところでは、大人数でチームを組んでの開発とゆうのは少なく、今回のプロジェクト のように人数が多い（現時点で10名って少ないか）のは珍しいため、どうも 「共有体制」というのに弱い様です。 が、これも克服すべき問題点ですから、がんばってみます。 （私自身がこれまで他社に出向＋管理される側だったのですが、今回体制を管理する側に 初めて回り、あたふたしているわけです） Kissinger様 うっ・・・EJB。プロジェクトにお金があったらAPPサーバ欲しかったのですが。 今回は予算上断念しました。 # JBossは開発基盤の設計時点でいまいち評価しきれなかった（当方の技術不足でです）ので # 見送りとしました。 私自身、これまでJavaの開発はEJBをガリガリ作っていたので（設計はあまりしてませんが） 本当にAPPサーバ欲しかったです。 ただ、今後の機能拡張を考えて、業務モデル部分をあとからEJBに変えやすいように、 今回の開発は進めています。（浅知恵でなければいいんですが・・・） > どの場合（たとえサーブレット、JSPだけで組む）にしても、表示用のコンテンツ生成と、 > ビジネスロジック、DBへのアクセスを分離して少なからず発生するだろう変更要求に > 耐えられるようにしたほうが良いと思います。 当初より、表示コンテンツ＋ビジネスロジック＋DBアクセスと分離して開発はしています。 （DBアクセスには一応DAOモドキのパターンを採用。モドキってとこが悲しいですが） 現在DBアクセスは皆様ご指摘通りJDBC＋SQLソース内ハードコーディングです。 今のところ、「SQLソース内ハードコーディング」を「PL/SQL」に置き換えても ビジネスロジックには影響しないようには最低限なっています。 この構成を守っていくというのは、今後の仕様変更・チューニング等で重要なのですね。 BUBU様 私もちょっと、OTNにあるJavaストアドプロシージャのドキュメント見てみました。 サンプルを見た感じでは、BUBU様のご指摘のような形で実装できるのなら、結構簡単で 便利なのかなとは感じました。 ただ・・・これまで「これは便利で簡単だ〜」といって飛びついて後でえらい目にあった ことは数知れず。すっかり臆病になってしまい、現時点ではJavaストアドプロシージャは 見送る可能性大です。（周りの意見も含めてです） しかし、今後のことを考えて勉強だけはしておこうかと思っています。 皆様、ご回答ありがとうございました。 どうも私が「Javaオンリー」に意固地になっていた気がします。 もうちょっと頭をやわらかく考えたほうがいいですね。 ご意見を参考にしてメンバーに相談、今後の方針を決めて行きたいと思います。 | ||||||||
|
投稿日時: 2002-10-15 10:57
パフォーマンスに関しては、処理の重さや内容を考えた方が良いと思います。 細かいデータ操作をSQLで投げるより高速なのは確かですが、その分、DBサーバの CPUパワーを消費するわけですから、度を越せばそのDBを使用するすべてのAPPに 影響がでます。 WebサーバやAPPサーバに比べて、DBサーバは多重化によるスケーラビリティが困難 なので（予算を含めて）、不要な負荷であればかけない方が安全だと思います。
Oracleの場合、ストアドプロシージャのデバッグには高価な専用の開発ツールが 必要でしたが、最近はもっと使いやすくなったということでしょうか？ 普及しているIDEに安価なプラグインを組み込むだけでOKということに成れば、 朗報に違いないのですが。 | ||||||||
|
投稿日時: 2002-10-15 13:05
unibon です。こんにちわ。
＃好みの問題も大きいと思いますが、私の考えをつらつらと書きます。 まず、ビジネスロジックを置く場所として、つぎの3通りが考えられます。 (1) DB のストアドプロシージャのみ (2) DB の外側(Java など)のみ (3) 上記(1)と(2)の混在 まず、上記(3)は、ロジックの中核がどこになるのかがあいまいになるので、 その点からは避けたほうがよいです。 また、上記(1)と(2)のどちらが良いか、という点については、 上記(1)は、速いかもしれないが、DBMS に大きく依存してしまう、 上記(2)は、遅いかもしれないが、DBMS への依存は少ない、 というように相反します。 さらに、ものごとを DBMS 主体に捉えるならば(1)のほうが良いですが、 今後 DBMS の種類を変えたり、あるいは、データの格納場所を DBMS 以外に置くことも考えると、 ストアドプロシージャを使わないほうが良いです。 しかし、これの逆も言えて、今後、Java 以外(C# や VB や PHP, etc.)で ビューを構築するようなことを考えると、 DBMS (のストアドプロシージャ)を拠点とすると使いやすいので、 ストアドプロシージャにビジネスロジックを集中させたほうが良いかもしれません。 また、コスト(環境としての値段)を考えてみると、 DBMS に比べれば、コンパイラや開発ツールはタダみたいなものですが、 DBMS は高価であるため、DBMS に縛られると身動きがとりにくくなるので、 その点からは DBMS に依存しない、すなわちストアドプロシージャを使わないほうが良いと 考えます。 | ||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。