http://d.hatena.ne.jp/JavaBlack/20061031 経由で、http://d.hatena.ne.jp/kanchan777/ とか、 http://q.hatena.ne.jp/1162199668 とか。
先に一言。基本的に極論＆暴言モードなのでご注意を(苦笑
個人的現時点での仮結論。
ストアドつかうな。
以上。
以下理由。
ビジネスロジックが散逸されると困る、ってのが最大の理由の一つ。
例えば… http://d.hatena.ne.jp/kanchan777/20061103 に、こんなSQLがあります。
SELECT o.orderID, o.date, sum(li.cost) as totalCost,
CASE WHEN
(SELECT SUM(li.cost)
FROM lineitems li
WHERE li.product = 'Talisker'
AND o.orderID = li.orderID) > 5000
THEN 'Y'
ELSE 'N'
END AS isCuillen
FROM dbo.CUSTOMERS c
INNER JOIN dbo.orders o ON c.customerID = o.customerID
INNER JOIN lineItems li ON o.orderID = li.orderID
WHERE (c.name = ?)
AND (MONTH(o.date) = ?)
GROUP by o.orderID, o.date
ORDER BY totalCost desc
論外。
いずれかの箇所に変更でもあったらどうするんだろう？
っつか定数書くなや、って思います。
割合に極論なのですが。基本的に「散らかってるほうが修正が大変」ってのが根底にありまして。
だからこそ、デザイン要素はテンプレートに閉じ込め、ビジネスロジックはModel(っつか、厳密にはEngine)に閉じ込めるわけです。
後それ以外の要素としては。
SQL(無論、含むストアド)はちと方言が多すぎて。DBMSが変更になる時なんかにえらく苦労するわけで、その辺も気がかりです。
過去に「DBMSが変わるような大掛かりな変更は相応の工数を掛けて然り」とかのたまう御仁もいらっしゃいましたが。多くの一般の方は「DBとWebのサーバって別でしょ？ じゃぁ片方だけ入れ替えてもいいじゃん」とか考えるわけですし、実際に要望も高いわけですし。だとするとその要望を「無下に一蹴する」事は、なかなか難しいのが現状です。
難しいだけであって、別に出来ないわけじゃないんですがね。
ちなみにそんな理由から、MWでは「SQL文を生成するクラス」ってのがいるです。方言の吸収用ですね。
ある程度の速度低下は発生しえますが、その辺はトレードオフなわけです。
あと、これはちょっと捻った見方ではあるのですが(そうは言ってもとても重要)。
「DB側で出来ることはDB側にやらせればいいじゃん」って発想でモノを作ると、そのうちコスト面でぶち当たります。
以前にも書いた気がするのですが。
Webサーバをクラスタリングするのは、割合にお安く済みます(最近でたいくつかのモノを組み合わせると、Linuxだとほぼ無料でいけそうだったりする)。
一方で、DBサーバをクラスタリングさせようとすると、概ね「桁で」上がっていきます。お値段が。
この状態で。WebサーバとDBサーバのどちらにより高い負荷をかけるように設計したほうがお値段的によろしいか。想像つきますね？
現実問題としてパフォーマンスは重要になるタイミングがあって。
ストアドは「事前にコンパイルされている」というメリットから、場合に応じては「選択すべき」ものになりえる可能性は、無論あるです。
ただ。それはきちんと考察を経てからでないと、危険のほうが多すぎる、そんなお話です。
少なくとも、言語とかアルゴリズムとか、もうちょっと先に気を配るべき場所は多々あるだろうに、って思っちゃいます。
Javaの場合…フレームワーク次第かなぁ？ 昔のJavaは好きだったけど、今の「太りまくってラッピングをくりかえしてる」Javaは嫌い。
常にシンプルで単純な原則を基準に、「必要に応じて最低限の例外」を許容。
多分これが一番無難だと思うのですが。
もちろん「何を持って最低限とするか」って突っ込みはあるんですがね。
議論云々ではなく、自分のスタンスの明示(割合に、対寺子屋向け)と、あとは自分のメモ用って感じでかきかき。
