適材適所
SQLとは難しいのです。
変なテーブル構成があったりするから。
SQL内にロジック（Logic in SQL）
では、SQLの機能を目一杯使ってみよう。
(中略)
これを「複雑なクエリ」と呼んだが、あくまでも先ほどの例で使った簡単な select と where だけのクエリと比べて複雑だ、という意味だ。
おいらには十分複雑なクエリに見えますが何か。
SQLクエリはもっと複雑なことが出来る。ただ、アプリケーション開発者はこれくらい複雑なだけでも避けちゃうんだよね。
出来るのと現実的かどうかはまったく違うぞ。
そんな複雑なことが何個でてくるかまで考えているのかこいつ。
数回試してみるのと百回にたようなのを書く必要がある場合では必然としてアプローチは違うから避けようとするの。
っつかこの実験は上記でいうところの(1)-1と(1)-2の比較であって、
ストアドプロシージャを利用した解ではない。
実績値で語れば(1)-1より(2)-2のが速い。
SQLだけでわーい3倍速い〜と喜んでみたところでストアド使えば100倍くらい速い。
実行結果時間の単位を秒単位から1/100秒単位に落としたら20倍も3倍も誤差の範囲みたいなもんだ。
ま、いろいろやりようはあるということです。
そもそも。
注文テーブルと注文明細のテーブル構造がある中で
注文テーブルに値段の合計が無いのがおかしかないかい？*1*2
ってなことがあるもの。
SQLは作り手によって千差万別の形を遂げる。
プログラムもそーだしな。
ゆえに記述の統一や、最適解の有効活用を行うためには
「できるやつがやる」のが一番いい。
10人いたら10人にSQL文を考えさせる必要などないのだ。
っという観点から物申すとDB専任者はいた方がいい。
10人規模じゃムダとかいう意見があったように思ったけれど、
10人もいたら入れとけと思うおいらがいてます。
UI側とPL/SQLならソースも違えば環境も違う。
ってことはまったく別の人がそれぞれ開発〜テストが行えるということ。
これはこれでアリな選択肢です。
適材適所は大事。
