それはJavaの問題ではないのでは

http://q.hatena.ne.jp/1162199668

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

普通に考えれば,特に理由がない限りは,ビジネスロジックは原則としてJavaの側に作るもんだと思うがな.ただ,あとの部分を見る限りは,理屈も分からないままに定説を鵜呑みにしているだけのように見える.

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

(論点が)違うと思うぞ.

私の小さなラップトップだと、複雑な SQL クエリは他の2つのアプローチよりも20倍も速かった。スッキリとした(でも時代遅れの)ラップトップからデータセンターのサーバにアクセスしたときのパフォーマンスなんかで結論を出すわけにはいかないが、複雑なクエリがこれほど速いとは思いもしなかった。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL#l4

というわけで,この20倍というのは「極めて特殊な条件では,そうなることもある」と言ってるにすぎず,「常に20倍の差がでる」と言ってるわけではない.ほとんどの場合はその差はもっと小さいだろうし,逆転することだってありうる.また,たとえ常に20倍も差が出るとしても,柔軟性や開発コストなどに決定的な差がある場合は,遅くても採用した方が良いという場合もよくあることだ.

SPの内部的な動作がDBのバージョンで変わることもありえますし、特殊なpackageはバージョンアップで使えなくなることもありえます。

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

Javaのことを分かってないように思う.
Javaでも,その問題が起きる可能性は0ではないが非常に低い.また起こっても比較的対処し易い.

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

コード次第だな.
Javaでベタに動的にSQLを書くのが得策でないのも事実だ.COBOLerが書いたJavaコードでは綺麗なコードなど期待できないだろうし,拡張性や保守性が高いとも思えない.

しかし良いコードであろうと悪いコードであろうと,DB屋さんが見れば「読みにくいコードだ」と思うだろう.よって「私には読みにくい」では反論としては弱すぎる.そもそも「多数決の暴力」の前には,専門家の意見さえも無意味なのだ.

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

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

結局はここなのでは.Javaのせいではなく開発者の能力不足が原因.*1

DB屋さんやCOBOLerにとってはJavaを使いこなすことが一番の難関で,最適な設計云々は二の次.自分の力量を見て判断してもらうしかないでしょうね.Javaが使えるならビジネスロジックJavaに書くべき.Javaが使えないけれどDBが使いこなせる人なら,ストアドプロシージャ(SP)もやむなし.しかしその場合でもSPにする理由は「パフォーマンスがいいから」ではない.JavaもDBも使えない人なら,何もさせないのが最良の選択になる.

*1:しかし単純なだけに,対策は極めて困難なのだな.