SQLが本当に簡単なら、なぜ本屋にあれほどの量の入門書が積まれているのでしょう？

tripodさん、こんばんは。

なぜでしょうね、上から潰すカスが大勢いることが一つの理由とは思っていますが、簡単なセミナーもやってる私には理解不能です。
もっとも、入門書の数でいうなら他の言語も同じで、むしろ少ないですけどね。

本文にも書いたけれど、これだけ拒否感が強いということは、皆さんが訴える方針に必要なスキルは簡単に取得できるのでしょう。その分、若い人や海外と果てしない競争が生まれます。

それで、大量に淘汰される人が出るのは、いつか見た景色です。

生島さん、こんばんは。

書籍については日本人が著者か邦訳されている書籍が多いだけでしょう。

>tripodさん
SQLで処理する量を増やすと記述しなければならない他言語によるロジックが
減るのは事実です。
それも他言語系で処理をするのとは比較にならない程減ります。

基本的にはプログラムのソースは短いほどバグが混入する率は少なくなり保守
性は高くなるはず。
# まぁ、これはO/RマッパーやLINQなどに対しても言えるのでしょうけど...

こんばんは．

> 単純作業化されたモノは、若い人や海外の人が競合相手になります。

私の周囲（首都圏）での営業面の感覚ですが．
もうすでに，人月 50 万円は古いですね．
人月 20 万円へと突入しつつあります．

> ですからこそ、業務知識を完璧に持っていて、今までコーディング経験がない顧客自身がコーディングする内製化に向いています。

内製化とまではいきませんが．

多分野の技術者の方が顧客の場合，Excel 表計算 ＋ マクロで仕様をいただくことが多いですね．これと同じにしてくれ，といって渡されます．Excel マクロの達人みたいな方がいらしたり．

RDBMS を使っているエンドユーザさんなら，もちろん，SQL ＋ 実行結果 で仕様をいただくこともあります．

後は，研究者の方が顧客の場合など，統計ソフトの R，SPSS 等の計算結果が仕様として出てくることが，ごくたまにあります．

> tripod さん
> SQLが本当に簡単なら、なぜ本屋にあれほどの量の入門書が積まれているのでしょう？

個人的な印象では，PHP，JavaScript のような Web （ホームページ）系が一番多いと思います．SQL も，ホームページ作るのに，MySQL を使う人をターゲットにしているとか．

入門書が一番多いというのは，すべての分野についていえると思いますよ（英語とか数学とか）．つまり，入門レベルを三日坊主で挫折する人の数が，中級・上級へと進む人の数よりも遥かに多いということ．

# 「サルでもわかる～」とか，「頭がよくなる～」とか，何か切実だなあ，と思ったり．
# ま，私も他人事ではありませんが．

こんばんは。

> ですからこそ、業務知識を完璧に持っていて、今までコーディング経験が
> ない顧客自身がコーディングする内製化に向いています。

1. 顧客が業務知識を「完璧に」持っているなんてことはあるのでしょうかね。
2. 業務知識が完璧だったとして、SQLをマスターしたとして、暗黙知→形式知変換プロセスがそれだけで可能になるというのは、問題を単純化しすぎでは？言うまでもなく、情報システムはSQLだけじゃ作れないので。
3. 仮に重要なビジネスロジックだけに限定したとしても、SQLだけで書こうとすると、それこそ巨大なスパゲティができあがりそうな。作った人しかメンテできないようなモノなら、効率は劣ったとしてもVBとかJavaの方がまだまし。
4. テーブルの正規化とか、トランザクション制御とかちゃんと考慮してくれるか心配。というか、そこまで勉強する時間が取れるのかが疑問。通常業務も当然あるわけなので。

コスト削減のために内製化をやってみたけど、結局、会社に損害与えてしまったという結果だと本末転倒。

「SQLを憶えてレッツ内製化！」というなら、もう少し具体的にどうすればいいのかまで書いてほしかったと思いました。

この記事では簡潔(単純)になることと、簡単になることが同じであると決めているように感じました。単純化した結果、簡単になる場合も当然、沢山あると思います。また、単純にした結果、それを使いこなすのに難しくなることもあると思います。

私はSQLなら少し使えますが、そろばんは全然使えません。
そろばんは数字を単純化していますが、私には簡単に使えません。
経理部長からしたら一人一台PCが使える時代でも、そろばんぐらい使えないと駄目だろうと、言われてしまうかも知れないですね。(笑)

色々考えることができて、楽しい記事です。
ありがとうございます。

ちょっと思い出したので参考にリンクをはらせて頂きます

簡潔さは力なり
http://practical-scheme.net/trans/power-j.html

皆さん、おはようございます。

saki1208さん、おはようございます。

> 基本的にはプログラムのソースは短いほどバグが混入する率は少なくなり保守
> 性は高くなるはず。

単純にそれだけのことですよね。
SQLは保守性が悪いと思う人は、結局、中途半端にしかSQLが分かってないのです。
実行計画をちゃんと読んでるのかな。

ronさん、flatlineさん、おはようございます。

同じ内容になるのでお二人に。

内製化については、
http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-f264.html
をご覧いただければ。

多分、ronさんのお客様は私の考える内製化に近いところまで OR 考えるとおりのところまで来てますね。
UIと内部と両方をお客様でするのは無理があるし、技術者でもこれだけ好き嫌いがはっきりしているのですから、向き不向きでどちらを自分たちでするか判断すべきでしょう。
ちなみに、これ以上詳しいSQLの書き方とか、考え方は多分書かないです。
セミナーで話することがなくなっちゃいますからね。

どんな言語で書いてもスキルが低かったらスパゲッティになりますよ。
SQLだからスパゲッティになると思うなら、まだ、SQLのスキルがプロのレベルにはないだけの話です。
私は言語のスパゲッティはイヤだな。

桑原光昭さん、おはようございます。

おっしゃるとおり、簡潔になっても簡単になるとは限りません。
PCもそろばんも、あるレベルにならないと簡単（便利）にはなりませんし、SQLもある程度以上のスキルにならないと、簡単にはなりません。

SQLは初心者に難しいモノを教えておいて、現場に出たら「そんなモノはダメだ！」って教えるから、出来なくなっているだけなんです。

おはようございます。

> 内製化については、
> http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-f264.html
> をご覧いただければ。

読んだのですが、具体的にどうするのかが書いてなかったので、
訊いてみました。「続きはセミナーで」というのであれば、まあ仕方がないですが。

ここ何回かのコラムの内容が同じで、目新しさがないですね。
持って行きたい方向が決まっていて、切り口を変えてそっちに誘導しているだけのような。
いろんな方の質問やご意見にも「忙しいから」といって回答していないし。全部に回答する義務はないんでしょうが。正直、単に答えられない質問が来ると、理由つけてボロが出ないようにしているだけに見えます。
個人的にはチームＡさんのご意見／質問に対して、生島さんがどう答えるのか楽しみだったんですけどね。

だんだんつまらなくなってきました。

本文に書いてあるとおり、「初級シスアドレベルが出来なくても良い」という人の話は基本的に聞くに値しません。

PCで文字が打てない人が「手書きの良さ」を訴えるのと、PCで文字が打てる人が「手書きの良さ」を訴えるのとまるっきり意味が違います。

「スパゲッティになる」って、「『っ』が打てないじゃないか！」みたいな感じかな。できないのはスキルがないだけ、そういう不毛な言い掛かりは知らんがな。

こんにちは．

SQL でラフな仕様をいただけるだけでも，SQL をもとに仕様の打ち合わせをできるだけでも，開発効率は上がりますからね．Excel も同様．

エンドユーザ ＋ SIer の体制で開発するなら，この辺が限度でしょう．

それ以上のこととなると，顧客の方でエンジニアを雇用しないと難しくなると思います．それが，本来の内製化の趣旨になるのでしょうけど．SIer イラネ，という．

色々な反論について．

コラムの前提をすっとばしているのは，スルーで良いと思います．「明示されてない」って，数学の証明じゃないんだから，前提条件を全て列挙して書くわけにはいかんでしょうに．ま，仮にそうしたとしても，彼らがちゃんと読むとは思えませんが．

コミュニケーションというのは，書き手・読み手両方の責任によって，成り立つものでしょう．例えば，「業務システムが対象」という，いままでに何度も，コラム本文・コメント欄に書かれている前提が読み取れないのは，読み手の責任だと思います．

きれいにまとめられた，教科書（アンチョコ）がないと，議論を理解できない，あまつさえ，それを，コラムの書き手のせいにする，というのはねえ．「ゆ」で始まる 3 文字言葉がどうしても浮かんでしまいます．

こんにちは。

> 読み取れないのは，読み手の責任だと思います．

それはその通りかもしれません。
逆に言えば、読み取れないのは、書き方が悪いからだとも言えますね。

立派な理念ばかりが並んでいるのだけど、
「それはそのとおりかも。でも、どうやったらその理念を実現できるの？」
という疑問は、当然わき起こってくると思うのですけどね。

あと、誤解されているかもしれませんが、私は「初級シスアドレベルが出来なくても良い」とは思っていませんよ。自分についてはね。パフォーマンスが必要な部分については、ストアドを積極的に使ってるし。
ただ、諸々の事情でスキルを身につけることができない技術者だっているというのに、そういう人たちの話を「聞くに値しない」ってのは、度量が狭いと思うだけです。

saki1208です。

いろんな人がいることは理解しているつもりですし、本当にどうしようもない場
合もあるでしょうけど...
>諸々の事情でスキルを身につけることができない技術者だっているというのに
何度も言ってますし、いろんな人も同様のコメントを記載されていますが、どん
な事情があるにせよ勉強しないのは本人の責任でしょ。

毎回この展開にするのはやめませんか?

> 毎回この展開にするのはやめませんか?

別にそっちの話を議論したいとかは思いませんよ、いまさら。
単に「○○な人の話は聞くに値しない」ってのは、度量が狭いという感想を言っているだけです。

これ形を変えて自説を繰り返してるだけでしょ？

コメント代わりもなにも答えになってないじゃん。

いろんなところで、発言がねじ曲げられるというのと同じでしょうね。
発言の一部を切り取ったらどうとでもなりますな。

「プロがプロとして飯を食ってる分野で、その分野を目指す一般の高校生に負けるようなことがあってはならない」相手は100年に一人の天才じゃない。合格率40～60％ですから多少出来る程度の普通の高校生です。普通なら、誰でも肯定する内容でしょうし、私なら、負けたら恥ずかしくて生きてられないな～。

そんなことがあっても良いというならば、逆のポジションから見ると、若い芽を腐った理由で摘んでいるのです。そして、腐った理由で顧客から利益を吸い取っているのです。

それを堂々と主張する人がいることに呆れています。
私はその腐った構造を何とかしたいのです。

誰かを守ったら、誰かが割を喰います。

誰を守るべきか、守られず割を喰うのは「出来ない方の人」になるのが、まっとうな社会でしょう。

「自分が飯を食ってる分野で、自分が飯を食っている分野を目指す高校生に負けるようなことがあってはならない」

なぜ、「自分が飯を食ってる分野」がSQLになったら答えが変わるのか？
私には意味が分からない。私が馬鹿なんだろうけれど……。

こんにちは。

主にJavaで作られているシステムの保守を行っている者です。
SQLを触らせたくないから、という理由で自動生成O/Rマッパーを支持してます。

というのもSQLを直接Javaで文字列として組み立てるような
コーディングをする方が非常に多いんですね…
引数次第で、どんなSQLが出来上がるか想像も付かない関数がコミットされてたり…
それならいっその事自動生成でいいから！JavaでSQL組まないで！！と言って。
複雑なものはSQL書ける方にJavaからの実行を考えずに
SQLのみを組んでもらったものをO/Rマッパー経由で発行しています。

触らせたくない、って言ってる時点で私自身
人に教えることから逃げてるかもしれないですけれど…

allocさん、こんばんは。

> SQLを触らせたくないから、という理由で自動生成O/Rマッパーを支持してます。

それで動く規模のシステムなら良いのでは。
データ量が増えて破綻したときはどうしようもなくなりますけどね。

私も何度も書いていますけれど、JavaなどでSQLを組み立てる（以外の方法もあるけれど）言語のスパゲッティは、どうしてもイヤです。

だから、無条件にストアドプロシージャにするのが良いといってるのですけれどね。

パフォーマンスの劣化も、言語の混在も、最大限に避けれます。

よっぽど下手糞が設計しない限り、スケールアウトで問題なんて起きないし……。

> それを堂々と主張する人がいることに呆れています。
> 私はその腐った構造を何とかしたいのです。

だから、何とかってどうするの？ってことを知りたい人が多いと思うんですけどね。
前のコラムで、チームＡさんも書かれてますが（３点め）、確かに「はず」と「べき」ばかりで具体的にどうしたいのかが何も書いてない。質問しても何だかんだで答えてない。
このコラムだって、「コメント代わり」にはなってないですよね。

そもそも何度もしつこく書いてるようですが、

> 「自分が飯を食ってる分野で、自分が飯を食っている分野を目指す高校生に
> 負けるようなことがあってはならない」

これはどうしてなんですかね？
別に負けたって死ぬわけじゃなし。

こんばんわ。
僕は生島さんのコラムを読むことで、また違うものの見方ができるのではないかと思って、最近SQLの勉強を始めました。今のプロジェクトはSQLは全く関係ないのですが、今後のために。

すみません、flatlineさんのコメントがどうしても気になったのでコメント記載させていただきます。

> だから、何とかってどうするの？ってことを知りたい人が多いと思うんですけどね。

そのような質問をしても、一個人のレベルで変えられるレベルの話ではないし、簡単に答えが出るようなものではないと思います。
一人一人が自分で考えて、共感できる人は同じような方向を目指せばいいのではないかと思います。
むしろ"「何とかってどうするの？」を聞いてどうするの？"と思います。

> これはどうしてなんですかね？
> 別に負けたって死ぬわけじゃなし。

たしかに生死の問題ではないと思いますが、そのこだわりが無くなった時点でプロとしてのプライドという意味では終わってますよね・・・。

生島勘富 さん　こんばんは。

いつも思うのですが、用語に誤りがあるのではないでしょうか・・・？

「SQL」→「ストアドプロシージャ」

こんばんは。

> むしろ"「何とかってどうするの？」を聞いてどうするの？"と思います。

「業界を変えたい」と言っている人がいるなら「どうやって？」は当然の好奇心だと思いますよ。
私の場合は単に好奇心でしかないです。具体性があって理想を言っているのか、ただのビッグマウスなのか。

> たしかに生死の問題ではないと思いますが、そのこだわりが無くなった時点で
> プロとしてのプライドという意味では終わってますよね・・・。

いや、そりゃプライドじゃないですよ。ただの面子でしょ。

flatline＝まりも

論理展開が全く一緒
相手が折れるまでエンドレス

無視するのが得策かと

> 相手が折れるまでエンドレス

ご心配なく。そんなにヒマではないので。
誰かを論破しようとか、そんな面倒なことも考えてないです。

flatlineさん＞

> 具体性があって理想を言っているのか、ただのビッグマウスなのか。

具体性がないと理想を言ってはいけないわけではないですよね。
好奇心から来るのでしたら、まずはflatlineさんで考えてみてその案をこちらに書かれてみてはどうでしょう？そうすると、話も進展していくかと思います。

> いや、そりゃプライドじゃないですよ。ただの面子でしょ。

プライドも面子も矜持も似たような意味なので、言葉遊びをするつもりはありませんが。
flatlineさんは高校生に負けてもプライドも面子も傷つかないということで了解しました。

＞初級シスアドレベル（高校生レベル）

初級シスアドを受験した高校生っていうのは、情シ科などで専門的な教育を受けている高校生が大半でしょ。で、その合格率が10%台なわけ。
ということはITを目指す高校生にとって初級シスアドは比較的難しい試験で、初級シスアド＝高校生レベルって言うのは詭弁か与太ってことになるよね？

東京大学に合格するのは大半が高校生だけど、それを根拠に東大（高校生レベル）とか言ってたらただのバカだと思うし、それを根拠に持論を展開してる人がいたら思いっきり疑問に思うのは当然でしょ？　エンジニア云々以前の問題としてflatlineみたいに突っ込みたがる人が出るのは当然じゃないの？

それにさ、高校生が合格する⇒高校生レベルとか言ってると、必要条件と十分条件の区別すらできないって見なされて損するだけだから、こんな変な理屈を繰り返し主張するのは止めた方がいいと思うよ？

> プライドも面子も矜持も似たような意味なので、言葉遊びをするつもりはありませんが。

プライドと面子は全然違う言葉ですね。

単に自分が恥をかきたくないのが面子。
恥をかこうがどうしようが、目的を達成しようとするのがプライド。

自分よりスキルの高い後輩に、SQL文のミスを指摘されたとして、
素直に受け入れて業務を達成するのがプライド。
恥をかくのがいやで聞く耳持たないのが面子。

いい年した社会人が面子で仕事するな、プライドで仕事しろと思いますね。

> flatlineさんは高校生に負けてもプライドも面子も傷つかないということで了解しました。

高校生に負けることで仕事がうまくいくなら、別に傷つかないですね。
○○に負けたら恥、なんて下らない面子でしかないですからね。そんなバカバカしいことに命かけてる人の気がしれない。
waonさんは、高校生に負けたら死ぬわけですか？生島さんは切腹するみたいですけど。

> まずはflatlineさんで考えてみて

いや、私は業界を変えたいとか考えてないので。変わるならどう変わるのかには興味ありますが。

んー、シスアド合格しただけの高校生に仕事で負けたら
恥ずかしくて会社に行けないかも・・・。(→離職→ノタレジニ)

それはさておき、

私は、ユーザー企業の情シスのものですが、SQLができるようになってからは
仕事がかなり楽になりましたね。

ちょっとしたリストの作成なんかはもちろんのこと、ユーザーから出てきた
要件を聞いただけで、SQLやらテーブル定義やらが頭の中にできあがるので
あとは書き上げるだけで完成まで持っていけるのが良いですね。

(ベンダーがつくった、カーソル作ってぶんまわしてってやってる
処理を全部書き直したい・・・。)

この感覚を他の人に伝えられなくて結局ひとりでやらにゃいかんのが
つらいんですよねぇ。もっとラクしたいのに・・・。

たぶん「ストアド」ではなく「SQL」で良いのではないでしょうか？

くだらない連投ですみません。

「いい年した社会人が・・・」は色々言い換えて言い返してみたいですね。

どちらかというと「面子も変なプライドも全部捨てて、がむしゃらに勉強しろ」って言ってみたい。(あ、うちの職場の人にですよ)

失礼しました。

皆さん、こんばんは。

多分、エンドレスなので止めたいのですけれど、プロを名乗るなら負けたイカンでしょう。

「SQLで書けばパフォーマンスは出ますが、私はIT業界を目指す高校生が受験する試験に出るレベルのSQLは書けません。それでも、遅くても、工数は掛かっても、動くモノは作れますから私はプロです」って顧客に言えるなら正しい。
言えないなら、高校生に負けたらプロじゃない。

この前提が通らないなら話にならないな。

過激な部分だけ切り出されると、本当に馬鹿げてるけれど、前提がもっと馬鹿過ぎる。

ちなみに、「ストアド」ではなく「SQL」で良いです。

基幹システムを丸ごと作っても、ストアドプロシージャの中でカーソルを回すのは2、3本ぐらい。
SQLがちゃんと書けるようになったら、UIに対して1回（レイアウトが変わる回数）のSQLで処理できます。

ストアドプロシージャは、インターフェースとしてSQLをラップしているだけです。

SQLで書いたあとは、O/Rマッパーを使おうが、他のモノを使おうが一緒です。SQLで書いてそれにO/Rマッパーでアクセスしても問題ないけれど、ストアドプロシージャにO/Rマッパーでアクセスする方がメリットはある。

宝春さんのところで、宝春さんと同じレベルの人が複数人いるなら、新規開発は安いPGを数名連れてくれば、どんな言語でもすぐに出来ます。

でも、同じレベルの人を複数人そろえるのが難しいのね。

ユーザの情報システム部には、サンデープログラマからの人が結構いて、その人達はSQLには向かいませんね。個人でやっているうちは、DBが必要な課題はなかなかでないので、どうしてもUIに興味が向かい、それが癖になります。

そこで覚えたやり方でやりたくなるのは、ユーザなら人情的に分かる。
だから、内製化するならどちらかに偏らせた方がいい。

おはようございます．

> flatline さん

> それはその通りかもしれません。
> 逆に言えば、読み取れないのは、書き方が悪いからだとも言えますね。

すみません．何をおっしゃっているのか，全く理解できません．

> あと、誤解されているかもしれませんが、私は「初級シスアドレベルが出来なくても良い」とは思っていませんよ。自分についてはね。

> 私の場合は単に好奇心でしかないです。

> いや、私は業界を変えたいとか考えてないので。

つまり，flatline さん自身はコラムの内容には無関係で，ただの好奇心でしかなくて，業界を変えたいとも思っていない，ということですか．

もう完全スルーでよいですかね．

皆さん、おはようございます。

どうでも良いのですけれど、私がコの業界に入ったとき、面接で「2年以内に二種（今の基本情報処理）が取れなかったら自分から辞めてね」って言われたモンだ。

でね。基本情報処理よりも下の試験ですし、今も同じように「まだ、初級シスアドすら取ってないのか！」みたいなことをいうオッサンがいる。
そいつらが出来ないのよな～。
取らなくてもいいから、出来るようになれ！

もちろん、私は情報処理の資格は何も持ってない。

おはようございます。

> すみません．何をおっしゃっているのか，全く理解できません．

言葉通りの意味です。
ある文章の意味がわからない場合、
書き方が悪いから読み手に理解できないかもしれないし、
読み方が悪いから書き手の意図が理解できないかもしれない。
それだけです。一方的に読み手のせいにするのはフェアじゃないでしょ。

> もう完全スルーでよいですかね．

「コラムの内容に無関係で」というのは、どういう意味なのかよくわかりませんが、ここを読んでるのは好奇心だし、自分で業界を変えようとは思ってないのは確かですね。
ここを真剣に読んでて業界を変えたいと真剣に思ってる人しかコメントしてはいけない、というなら、スルーでいいですよ。別にコメントのコメントが欲しくて書き込みしているわけではないので。

おはようございます。

> 「SQLで書けばパフォーマンスは出ますが、私はIT業界を目指す高校生が
> 受験する試験に出るレベルのSQLは書けません。それでも、遅くても、
> 工数は掛かっても、動くモノは作れますから私はプロです」
> って顧客に言えるなら正しい。

プロという言葉のフォーカスが違うだけですね。
私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げずに完遂することですね。その過程で高校生に負けようと関係ない。
もちろん完遂するということは、パフォーマンスや工数の条件を満たしてということです。
お金をもらって仕事をするというのは、そういうことでしょう。
プロスポーツ選手じゃないんだから、誰かに負けないとか、そういうことではないでしょう。

まあ、考え方は人それぞれだし、それぞれフォーカスを当てる場所は違うわけで、キリがないので、これぐらいで。

> 私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げずに完遂することですね。その過程で高校生に負けようと関係ない。
> もちろん完遂するということは、パフォーマンスや工数の条件を満たしてということです。
> お金をもらって仕事をするというのは、そういうことでしょう。

こんなことは今更得意気に言われるまでもなく社会人として当然で。ここではその先の話をしているわけ。

> プロスポーツ選手じゃないんだから、誰かに負けないとか、そういうことではないでしょう。

よほどの生ぬるい仲良しクラブでやってきたとしか思えない。フォーカスの違いじゃなくスコープの違いね。視野が狭いと言わざるを得ない。

flatline氏
>プロという言葉のフォーカスが違うだけですね。
>私が考えるプロは、自分のスキルはどうだろうと、会社から与えられた業務を逃げ>ずに完遂することですね。その過程で高校生に負けようと関係ない。

生島氏
>「SQLで書けばパフォーマンスは出ますが、私はIT業界を目指す高校生が受験する>試験に出るレベルのSQLは書けません。それでも、遅くても、工数は掛かっても、動くモノは作れますから私はプロです」

なんというか、もし私が会社から顧客へ生島氏が言うような形で紹介されたならば
会社に対して文句の一つでも言うか、自分が本当にその程度なら必死で勉強するでしょう。

いくら納期や契約が守れても、そんな状態じゃ技術者ではないでしょう。
そういう意味でflatline氏はスゴイと思いますよ。

たぶん議論の前提となるベクトルが全然違う方向に向いているのは。

はじめまして、主に組み込み開発をやっている者です。
いつもCやアセンブラ、VHDLなどをやっているので、SQLなんて「超」高級言語にはあまりなじみはありませんが、色々気になることがありましたのでコメントさせていただきます。

私がソフト(今はハードもやりますが)開発に携わる前、PCのサポートの仕事をしながら初級シスアド、基本情報、ソフトウェア開発技術者の資格を取得しました。
その過程でSQLも多少かじったことがあります。

私の感覚としても、これらの資格を取得可能な知識レベルを持たずにソフトウェアのエンジニアを名乗るはおかしいと感じるほど簡単な試験だと思います。特に初級シスアドは最も簡単かつ使用者の側の資格ですから、開発者としては満点に近い点数をとっても当たり前といえるかもしれません(特に業務系の開発者にとっては)。

ごくごく単純なことで、SQLを勉強してスキルを身につければ、業務系のシステムを効率よく開発できるようになるので、勉強しましょうという話ですよね。その点は私はそのとおりで疑問の余地はないと思います。「テレビのリモコンを孫の手で押す」なんて例えは秀逸だと思いました(笑)。

ただ、やはり生島さんの文章はちょっと気になるところもあります。以前のコラムに「どちらかが当てはまるなら、この先を読むのは無意味です。IT業界で仕事をするセンスが決定的に不足しているので、転職を考えた方が良いでしょう。」
なんて書いてあって、何様のつもりで書いているんだって思いました。理屈ではなく感情として反論したくなりました。

単純に理屈として考えれば、理解できる文章ではありますが、やっぱり文体がちょっと・・・毎回炎上してしまうのもしょうがないかなと思います。

やっぱり、納得いかないな。
「効率化」は必要条件の１つでしかない。
そもそも効率化なんていうのは、もともとコンピュータの持っている性格から発するものなのだから、あえて言うまでも無く当たり前のことでしょう。
そして、今の時代を考えるに（私見ですが）効率化は、ベースとして存在はしていますが、求められているのは、当たり前の効率の上に作られる付加価値やサービスなのでは？

>会社案内を配って歩いたり、TVでCFを流すよりも、24時間世界中に営業できることになり効率的なので採用されるわけです。
これも、効率は当たり前の事として、その効率の上に、で何か新しい物・試などをプロモーションしますよね？

RDBMSオブジェクトを効率よく使えない人に憤りを感じているから、SQLと言っている間は「ウンウンそうだな」とも思っていましたが、
「本音は効率化なんだ！」とされると、「今更何を・・」という感じを受けてしまいました。

oumiさん、こんにちは。

> これも、効率は当たり前の事として、その効率の上に、で何か新しい物・試などを
> プロモーションしますよね？

当たり前ですよ。
その当たり前すらないがしろにしているから、効率を犠牲にしたらダメっていってるだけです。

そう書いてあると思いますけれど。

>そう書いてあると思いますけれど。

今回だけを見ると、そう書いてありますが、前回の流れも踏まえて、
「効率が全てだ」の裏付けと言うか、コメント？として読んだので、違うなという感じを持ったのでした。
前回の記事で、流れ的に「効率が全て」というように読んでしまったので。

でも、その当たり前の効率化もできてないＰＪって意外に多いですよね。
汎用機からの全面リプレースで、WEBにしたら使い勝手が逆に悪くなって
クレームだらけ、とか。

よくヒアリングして、設計すればいいのかもしれませんが、大規模業務系
とかいくつもの会社が入りこんでいたり、要件詰める会社と設計以降実施
する会社が分かれていたりすると発生しやすいようにも思えます。

そんなケースは、○○が悪いんだ、や××を△△してから□□すればいい
んだなど理想論はあるのでしょうが、少なくとも私が見てきた中でそこまで
キレイにモノゴトが運んだとこを見たことがありません。

こんにちは。isuzです。

いきなりですが、他人のレスに横槍をいれさせていただきます。

oumiさん
＞そもそも効率化なんていうのは、もともとコンピュータの持っている性格から発するものなのだから、あえて言うまでも無く当たり前のことでしょう。

おそらく生島さんは、そのように考えてる人が少ないと感じるからこそ、ここで声をあげているのではないかと思います。
「本音は効率化だ！」というのも、今までのエントリでそれを汲み取れない人用なのでは？
#少なくとも私はそう読んでいます。なので、正直最近のコラムはツマラナイ感がありますね。

当たり前の事さえ出来てなければ、その上での付加価値の話なんて…って感じでしょう。
でも、そろそろ次のステップの話も聞きたいかなーと思います。

oumiさん、こんにちは。

> そして、今の時代を考えるに（私見ですが）効率化は、ベースとして存在は
> していますが、求められているのは、当たり前の効率の上に作られる付加価値
> やサービスなのでは？

この言葉を聞いて、たぶん10年～15年以上前、何かの研修だったか、先輩の言葉だったのか忘れましたが、

「業務システムの本当の価値は、システムそのものではなくて、システム化されたことによって生み出された余剰時間と、その余剰時間によって創造された新しい何かだ」

という意味のことを言われたのを思い出しました。

昔から本質は変わってないってことですかね。

> でも、同じレベルの人を複数人そろえるのが難しいのね。
そうなんです。なかなかいないんです。

残念ながら、うちにはひとりもいません；

ていうか、かれこれ７～８年ほど、コの業界にいますが
いままでに２人？くらいしか会ったことがありません。

私なりにがんばってみますが、生島様！勝手に期待してます！

こんばんは．

> 掛かるコスト ÷ レスポンス数 ＝ 1件のコスト

効率 ＝ 売上（もしくは売上に結びつく何かの数量）÷ コスト

# 効率は高い方がよいはずなので，逆数にしました

だとすると，これは，

付加価値 ＝ 売上 － コスト

と同じもの，ということになりそうですが．

通常，付加価値と呼ばれるものは，「粗利」に近い概念ですから．
（生産性と呼ばれるものは，この付加価値を労働者の人数割りにした値）

付加価値とは ～ exBuzzwords用語解説：
http://www.exbuzzwords.com/static/keyword_566.html

これ以外の付加価値って何があるのかな，と疑問に思いました．

はじめまして。
割と大手のSierで若手プログラマ兼SEとして働いているものです。
ここに来るような技術者の方々に偉そうなことを言える技術はありませんが、
お客さんも来ているようなので、その方々に対して私なりの解説を。
思いのほか長くなってしまいました。申し訳ありません。

私のプロジェクトでは業務系(データを入力したり削除したり)部分はプログラミング言語(C#)、情報系(過去の売り上げを参照したり)部分はSQLで書いていました。
その経験では確かにSQLの方が圧倒的に早いと思います。
本当に５倍くらいの開きはあったかもしれません。
※但し、この場合処理の複雑さが違うので単純に比較はできません
機能を追加・変更したり、見栄えを良くするのはプログラミング言語を使ったほうが有利だと思います。テストもしやすいし。
この効率と拡張性のトレードオフが技術的には争点でしょう。これはケースバイケースだと思います。私の意見としては大雑把に言うと、扱う業務が大規模、複雑ならプログラミング言語。小規模、単純ならSQLをお勧めします。

二点目、「初級シスアドレベル」というやつですが、これはかなり低いレベルです。
私も生島さんの言い方や、10年泥のように働け！というような考え方には反対しますが、DB扱っててselectもろくにできないのはどうかと思います。
生きる価値がないとは言いませんが、別の業界に行けばいいと思いますよ。
よく技術がないと槍玉にあげられる「大手Sier」のうちのPMだってこれくらいならすぐできます。たしかに汎用機世代には出来ない人が多そうですが、総数としてそんなに多いんでしょうか？
私としてはむしろそこが信じられません。と、それくらいのレベルです。

三点目、と続けようと思いましたが、矢鱈長くて読みづらいのでこの辺で切り上げます。

皆さん、おはようございます。

> 付加価値 ＝ 売上 － コスト

そのとおりですね。
結局、どんなファクターも最終的に効率的かどうかで判断するしかないです。

変更工数が掛かるというのは、まぁイロイロと。
「遅いときにはSQL」って方針でやってるところのSQLは、ただただ長ったらしく書いてサブクエリーてんこ盛り。「何じゃこりゃ？」ってのがほとんど。

できる人が書いたら、ちゃんと意味が通っているから保守もし易い。

プロジェクト（会社）として逃げてると、いつまで経っても全体のレベルが低いままになるので、中途半端な適応が一番いけない。

要は、できない人に合わせるか、できる人にならせるか。

上に立つ人間ができない人だから、「できるようになれ！」となかなか言えない。
すると、できない人に合わせることになる。
結果、納品物が高校生以下になる。

結果を見たら詐欺でしょう。

これほどの差が出るのは他のモノではない。
一番ひどいから取り上げているのですけれど……。他がどうでも良いとは、もちろん、全く思ってない。

今週末のセミナーには、WHERE句すらまともに使ってないと思われるベンダーの作ったシステムを使われているエンドユーザさんが来られる。
全くの未経験の方に2日間でどこまで伝わるかな。
未経験から、

http://www.g1sys.co.jp/seminar090515_answer.html

まで行けたら、SQLの教育コストって、もうとんでもなく安いってことになるんだけれど。
多分、使えるプロジェクトがそうはないから、すぐに忘れるでしょうけどね。

私が言った付加価値とは、経済や工業においての付加価値の事では無く、一般的な意味で付加価値という言葉を使ったのです。

「当たり前の効率の上に作られる付加価値やサービス」でいう付加価値とは、独自の価値やサービスが付随するケースを指しているのです。

効率化が全てだ！という事や数式は、おそらく「経済においての 付加価値」を言っているのでしょう。逆に、経済や工業以外で「付加価値」と言う場合は、「独自の価値やサービスが付随するケース」となるのであろうと思います。例えば、顧客の満足度なども経済的な付加価値とは別の意味で付加価値となります。
我々サービス行においては、単純に経済だとか工業だとか決めることが難しい、状況・状態によって異なってくる「付加価値」があります。

故に、「好意的に読まないと」という事になるのだと思います。
なんだか最近の記事は好意的に読まないと、本来の意図とは違う方向へ読み取れる感じになってきている気もするのです。

ちがうんだ「経済の話なんだ」と言われたとすると？
「ふ～ん」というしかないんですけど・・・

何に反応したか。

>「効率化すること」は最も重要な大原則です。
まぁこういったような事に反応したわけですが。

私の感覚では、効率的である事は「最も重要な大原則」でもなんでもなくて、コンパイルエラーの無いコードを書く、程度に基本的な事だと思っています。
そして、そのような基本が出来ない人がいるから、声を大にしてSQLの知識を！
ここまでは解ります。というか賛同しています。
RDBSMに関わる技術者全員が、基礎素養としてシスアド級のSQL知識は必要だろ！
もそうです。

このような事に意を唱えているわけではないのです。

でも、基本的な事だと思うゆえに、効率化が全てでは無いのです。たんなる期待される要素の１つにしか過ぎないのです。なので「システムは効率化の為に！」なんて言われると、いつの時代の話？と思っちゃったわけです。
「RDBMSを効率よく使うために！」の方がストレートで伝わる気がしました。

もちろん、アナログな業務プロセスをコンピュータに載せ換えるってだけの、業務システム開発を前提にするなら、まぁよいのでしょうけど・・
12年くらい前でも、単なる会計システムでさえ、当たり前の機能は当たり前に、そして「何か新しい提案は無いのか！」なんて、そっちがメインだったりしましたから・・・(プロモーションが絡むシステムだともっとね。)

まぁ、そういう感覚・状況の人間もいるってことで・・・
納得いかないと言っているだけで、ゴールを否定しているわけではないのです。

なんか似たような事繰り返して言ってるか・・・・自重しときます。

あのー。。。

私は、「SQLを知らない(わかってない、文法しかあってない)」時と
「SQLがわかってきてから」とで 世界がけっこう変わりました。

生島様もはじめはこの感覚的な部分をみんなに伝えたいというような
内容からはじまってたような気がします。(読み返してないので違ったかも)

私はこの感覚的な部分を体験してもらいたいという思いがあります。

ところが、ここ最近はどうも違う方向にいっているような・・・？

システム化することというのは、効率化も大事だと思います。
そうじゃない付加価値だってもちろん大事でしょう。

誰かが「効率化がすべてだ」と言ったからといって、別にそんなところで
反論なんかせずに「ふーん、私は違うけどね。」ってさらっと流しても
良いのではないでしょうか？(それともわざと煽ってたのかしら？)

皆さん分かっててやってる感もありますが
どうもここんとこのギスギスした感じが気になってしまいました。

宝春さん、こんにちは。

おっしゃるとおりです。
「セミナーを売りたいな」と思って路線変更したので、その辺からね（苦笑）。
敢えて書いてないことが多かったり。
どうせ売れないから全部書いてもいいんですけれど、セミナーに来てくれた人に申し訳ないし……。

段階は、

　　　　1.全く分からないレベル
　　　　2.単文なら分かるレベル
　　　　3.初級シスアドレベル
　　　　4.文法がほぼ分かるレベル
　　　　5.会話のスピードで分かるレベル

とあって、「私は出来る」って言ってる人の90％は文法だけじゃないかな。
4.が一番まずくて、本人は出来てるつもりだけれど、シンタックスエラーがないだけなので、4.の書いた複雑なSQLはとても読めない。
4.が作ったテーブル設計も、大抵マズイ。
確かにそれはメンテできなくなる。

5.まで来ると、RDBMSを使う限り、他の言語と効率がひっくり返ることは理論上あり得ない。

多くの人が4.で止まるのは、そもそも、文法から教えるのが悪いのであって、会話のペースで出来るようになるには、文法は無視すればいい。文法はインターネットなり、リファレンスで都度調べても、他の言語でやるよりも遙かに早くできる。

会話のペースでできるようになると、過去の自分のソースは恥ずかしくて見れなくなるし、果てしないほど非効率なのも分かる。

宝春さんが大手のベンダーに依頼していたとしたら、果てしなく非効率な連中にトンデモない金額を払っているということも気づくでしょう。
社員の立場ではトンデモなくても所詮は会社の金なので関係ないかも知れませんが、経営者としては許せないです。

>宝春さんが大手のベンダーに依頼していたとしたら、果てしなく非効率な連中にト>ンデモない金額を払っているということも気づくでしょう。

ギスギスするのは、こういう物言いのせいなのでは・・・

生島様

なるほど。商売の邪魔しようとしてましたか、失礼しました。
空気読めずにごめんなさい。m(_ _)m

> 宝春さんが大手のベンダーに依頼していたとしたら、果てしなく非効率な
> 連中にトンデモない金額を払っているということも気づくでしょう。

カーソルループでIF文がごちゃごちゃ書いてあるソースは、ホントかんべん
してほしいです。
SQL一個で書けば、もっと単純でわかりやすくてメンテしやすいし処理時間も
1/10以下にはなるのになんでわざわざ複雑に考えるんだろう？って思います。

今これをやられたら、ブチキレるか とことん冷たく接しますね。

でも、これはユーザー側の問題でもあるのでしょうね。
ユーザー側が早い段階でベンダーに業務を伝えられていないのかもしれません。

ぶっちゃけ、詳細設計書なんてどうでもいいから、お互いにしっかりと
外部仕様書を作り上げるのが大事なのかな。
#ここで、SQLが重要なんですよね。

そうそう、ひとつ苦言を申し上げますが、こういうとこではあまり商売っ気を
出さないほうがいいのではないでしょうか。
オチが「続きはセミナーで」では、そりゃ反感買います。

まぁ、私としても４から５に移行する人が急に増えても、商売あがったりで
困りますので出し惜しみしちゃってください。(笑)

oumi様

これでもけっこう柔らかい表現だと思いますよ。

oumiさん、宝春さん、こんばんは。

皆さんは、ほとんど1対1でも、私は1対多で管理画面でコメントを見たら2200以上あって、何百回かは私がおんなじようなことを返しています。私としては、かなり気長に構えていたのですが、それでも、やっぱりストレスは溜まるモノです。

それじゃあ、ダメなのでしょうけれど、ブログとか荒れて来てやめる人が出るのは、そういうのが理由ですよね。

もうちょっとちゃんと読んでくれよ。ってのが出てしまう幼稚な人間なのです。
Mixiのように馴れ合いは嫌いですので、まぁ、キレ芸と思って見て下さい。

> ぶっちゃけ、詳細設計書なんてどうでもいいから、お互いにしっかりと
> 外部仕様書を作り上げるのが大事なのかな。

会話のペースでできるようになれば詳細設計は要らない。

全部ストアドプロシージャにしてこれ。
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
最終的にどうしてもループが必要になっても対応できるし仕様も簡単に固まる。

商売っ気というか、@ITも私もお互いに最初から商売ですよ。

度々お邪魔しております。
yHiroと申します。

ちょっとだけ、宝春さんのコメントが気になって。

私も会計系のシステムを中心とした開発で食っているのですが、Cursorを使用したループ内部IFは案外使います。

画面キックで裏でストアド(SQL)などであれば単発のSQLでいいのですが、夜間バッチなどの大量データを処理する場合などはどうしても使用せざるを得ません。(エラー時の対象外判定やハンドリングなど)

以前、そのようなバッチ処理をCursorによる取得・Insertから単発SQLによるInsert-Selectに変えられた事があり、エラーハンドリングで実際の処理が実務に耐えられなくなったことがあります。(Select>例外処理>エラー対象取得のSQLをExceptionで十数個　規模感の問題もあり)
まあ、こんなのは対象外としても、宝春さんが見られている処理がどのようになっているのかは存じないのですがベンダーもそういうところを考えた結果なのではと思った次第です。

お目汚し失敬しました。

> yHiro さん

こんばんは．

> 以前、そのようなバッチ処理をCursorによる取得・Insertから単発SQLによるInsert-Selectに変えられた事があり、エラーハンドリングで実際の処理が実務に耐えられなくなったことがあります。

トランザクション処理で，トランザクション単位（粒度）無視はまずいですね．
（バッチ処理でも例外ではない）

私は，ひそかに，「単発SQLによるInsert-Select」を，
「テーブル単位トランザクション」アンチパターンと名付けてますが（笑）．
類似のものに，「書き込み前に必ずテーブルロック」アンチパターンがあります．

超巨大データの INSERT を 1 トランザクションで実行，失敗して，ロールバックがいつまでたっても終わらない，というパターンとみました．

集計でも，RDBMS 上でトランザクションが動いているような場合は，わざとカーソル・ループにしたり，1 回ワークテーブルにスナップショットとったりはしますね．

Oracle ですと，「スナップショットログが古すぎます」エラーが定番．レスポンスタイムより，UNDO/REDO 領域を節約したい，というケースはありますね．

まあ，宝春さん がどういう処理を念頭においておられるのか定かではないですから，何とも言えませんけど．

> Select>例外処理>エラー対象取得のSQLをExceptionで十数個　規模感の問題もあり

む．

よく読むと，「RDBMS の制約（constraint）をアプリのチェックロジックに使用」アンチパターンも該当しますね．

データ処理の鉄則：
「データはその発生源により近いところで処理すべし」

# 連投失礼しました．

皆さん、おはようございます。

どうしてもロールバックセグメントが大きくなりすぎる超巨大でない限り、INSERT - SELECT のパターンで良いのでは？

ループしても、しなくても、整合性チェックはINSERT前にやるべきと思いますけれど。

エラーをはじくためにワークを使うことはありますが……。

　　　　ロック

　　　　エラーチェック
　　　　（エラーデータをエラーログにINSERT - SELECT）

　　　　INSERT
　　　　…
　　　　SELECT
　　　　…
　　　　WHERE
　　　　　　…
　　　　　　AND NOT EXISTS
　　　　　　　　　(SELECT * FROM エラーログ
　　　　　　　　　WHERE エラーログ.キー ＝ メイン.キー)　　　　

　　　　ロック解除

みたいな感じかな。
固定長テキストの読み込みとかではループしますけれど。

おはようございます。

ronさん:
>「テーブル単位トランザクション」アンチパターンと名付けてますが（笑）．
>類似のものに，「書き込み前に必ずテーブルロック」アンチパターンがあります．

言い得て妙ですね。僭越ながら私も使わせて頂きます。(笑)

生島社長:
私の場合、対象が大手企業さんの仕訳情報や債権情報でしたのでそれはそれは大きなトランザクションでした。
エラーログの出力もプロジェクトのルールで導入パッケージに準拠した方法でとのことで大部分の機能ではワークテーブルに出力するなどの柔軟な方法が取りにくかったのもあります。(これは言い訳か？)

例にされたパターンは判りやすくて良いですね。
参考になります。
スクラッチ開発のプロジェクトに入ったら応用させて頂きます。
固定長テキストやcsvなんかはローダーでワークに放り込んでから処理とかは結構やりますね。

とにかく繰り返し言ってるのは、開発の初期に前のコメントぐらいの説明がさらっと理解できない人が混じると、議論すら成り立たないので困るということです。

相手が分かってないとき、それなりの職位にある人に言語解説はできないのよね。

でも、初級シスアドレベルでもちゃんと理解してたら、前のコメントぐらいは普通です。初級シスアドのレベルは超えてない。
超えてたら、「その手もあったか」で済むでしょう。

いろんな制約はあるでしょうし、ループの方が良いときもありますから、押し付けるのが目的ではない。せめて議論できるレベルになってよ。ってそれだけなのです。

いろんな制約ができるのも、議論が成り立たないレベルの人達が大勢いるからで……。

結局、堂々巡りです。

こんにちは。

繰り返しのおうむ返しになってしまうので、極力控えますが・・・。

どうも、「仕様を聞いた段階でループが頭に浮かんでいる」印象を受けました。
(違ったらごめんなさい。)
いや、私だってもちろんループもIF文も使いますけど、「そうじゃないんです」。

宝春さん、こんにちは。

多分、ほとんどの人はループが頭に浮かんでます。私も仕様というか要件を聞いた時点で、どちらが先かというと微妙。まぁ、両方です。

ループが浮かぶ人は、それは実行計画ですから、

　　　　実行計画 ⇒ SQL

の練習をすればよいのです。
すると、最初からチューニングしたのと同じSQLが書ける。
弊社のセミナーはそんな感じになります。

最短距離でSQLを覚えようとすると、ループを否定しないことじゃないかと思う。

あとはどこで切ったら良いかの判断ですが、O/Rマッパーを使う前提などがあると、とにかくバラバラに切った設計になってしまうから、私にとって「O/Rマッパー」はエネミーです。
多くの人にそういう癖を付けてしまって、それが文化になってしまうからね。

頑固なのは私じゃなくって、ループしか見ない人だと思うのですけどね……。

こんばんは。

宝春さん:
引き合いに出して済みません。
仕様を聞いた段階の話であれば、ループ/単発などよりもデータの取得方法を先に考えますね。データソース(From)と取得方法(Where)を頭で構築して、データソースの規模感と処理タイミング等で単発/Cursorのいずれを使用するかを考えます。
ざっくばらんに切り分ければ、画面系からの裏バッチなどでは単発、夜間日時処理や月次処理などの処理時間の余裕や規模と処理後(夜間処理なら翌朝)の保守が参照するログの精度を考えるとCursor～Loopで細かく検査というような感じでしょうか。
何よりユーザにストレスを与え無いシステムが必要なわけで、機能によってレスポンスか精度(ログ等の)によって考えている･･･つもりではあります。

生島社長:
『前のコメント』とは私でしょうか？
こんなことしか書けない汎用機含めの10年オーバー選手ですが、多少なりとも見込みありとして頂けるのであればありがとうございます。
何にしろ、精進ですね。

こんばんは。

どうも自分の名前が出てくると、そわそわしちゃって・・・。

yHiro様

いえいえ、どうも。
私の場合、そのような処理を行うときは、まずエラーデータ(使えない・
要らないデータ)を捨てますね。
それから正常なデータだけをINSERT･･･SELECT･･･で処理します。
要件によっては、エラーデータごとなんてこともあります。
処理の流れは、ちょっと前の生島様のコメントをもう一度ご覧ください。(ぉ
たぶん、レスポンスも精度も犠牲にはしませんよ。

UIの方は詳しくはありませんが、基幹系・情報系のシステムでは
夜間バッチだろうがUIだろうがおそらく同じように処理できると思います。

まぁ私の場合、捨てっぱなしでエンドユーザーから後でつっこまれることも
しばしばありますが(冷汗)
ていうか、犠牲にしてるじゃないか orz

パッケージのカスタマイズなんかだとなかなか自由にできないでしょうし
捨てっぱなしなんてもってのほかだとは思いますが
基本的には、SQL+この流れでいけるのではないでしょうか。

こんばんは．

> 生島さん

> どうしてもロールバックセグメントが大きくなりすぎる超巨大でない限り、INSERT - SELECT のパターンで良いのでは？

生島さんの挙げたパターンは保守ではよく使うのですけど．

アプリからやるのであれば：

　FOR トランザクション単位 IN (
　　SELECT * FROM 入力テーブル
　　　WHERE 取り込みフラグ = OFF
　) LOOP
　　
　　ロック獲得
　　
　　エラーチェック(トランザクション単位）
　　
　　IF エラー THEN
　　　エラーログ書き込み
　　ELSE
　　　INSERT INTO テーブル1
　　　　VALUES トランザクション単位
　　　
　　　INSERT INTO テーブル2
　　　　VALUES トランザクション単位
　　　
　　　...
　　　
　　　UPDATE 入力テーブル
　　　　SET 取り込みフラグ = ON
　　　　WHERE トランザクション単位
　　　
　　END IF
　　COMMIT
　END LOOP

の方が，ベターじゃないですかね？

理由は以下のとおり：

　1) 処理の進捗状況がわかる
　　
　　SELECT COUNT(*) FROM 入力テーブル
　　　WHERE 取り込みフラグ = OFF
　　
　　もしくは，
　　
　　SELECT COUNT(*) FROM テーブル1
　　　WHERE 更新日時 >= 処理開始日時

　2) 処理途中で強制終了しても OK
　　（次は中断したところから再開）

　3) 他のトランザクションを並行で走らせるのも OK

　4) どちらにせよ，アプリはトランザクション単位を，自身のメモリに読み込んでしまっているのだから，それを使わないのは無駄

> 宝春 さん

私の考えでは，

1) DB からの READ : SQL > ループ

2) DB への WRITE : ループ > SQL

です．

データ量を増やしたとき，どちらがより負荷に耐えられるか，パフォーマンスが得られるか，という観点からすると，こうなるはず．

データの流れは，READ と WRITE で逆方向になるわけですから，実現方式の検討も，逆にならなければおかしいでしょう．

もちろん，ループしか検討しないのは，論外だとは思いますが．

皆さん、おはようございます。

クライアントで一括でやった場合（バッチは基本サーバ側で処理しますが）でも、ロックしてもクライアント側のメモリーには載りません。
ロックしてもREADするまではクライアントに読み込まれません。
ちなみに、1件READしようとすると、ミドルウェアの設定ファイルで指定されている件数（セッション単位で変えれるハズ）同時読み込みします。

つまり、INSERT - SELECTでやっている限りは、クライアントにデータは転送されないのです。

UNDO領域が気になる量であるなら、その気になる量をクライアント（APサーバかな）に転送することの方が問題になるでしょう。

多分、クライアントからループで回すのと、一括処理を比べると、20～100倍ぐらい処理速度が変わります。20分の1の時間砂時計と、20倍遅くて進捗バーが出るのとどちらが良いかというと、大抵は「砂時計」を選ぶことになると思います。

どうしても進捗が見たければ、ストアドプロシージャで1件ずつコミットして、別セッションからコミットされた件数を数えることですかね。

ストアドプロシージャで回せば0.5～20倍ぐらいの差じゃないかと思います。
処理によっては回した方が速いときもあります。
でも、ストアドプロシージャのループって書きにくいし読みにくいので、進捗が見えることが重要な要件でない限り、私は、一括でやる方を選びたい。

これは個別の判断になるので、設計の段階で議論ができる状態になれば良いのですけどね。

闇雲にSQLって言ってるわけじゃなく、くどいけれど、議論の対象者が初級シスアドレベルにすらなかったら、噛み合わなすぎてイライラするわけです。

追加。

JDBCは 最初に.Next()ってしたときにデフォルトの10件を読み込みます。
次に.Next()ってしたときにはクライアントのメモリーから読み込みます。
つまり、JDBCとサーバのやりとりは、.Next()の10分の1しか内部的には起きていません。

デカイセットを読み込む処理のときには、
　　　　setFetchSize(256);
みたいにセッション単位でフェッチサイズを大きくしてやると速くなることがある。（というか大概速くなる）

ODBCとか、oo4oとかも、基本的に同じ。
「フェッチサイズ」などのキーワードで調べましょう。

私はクライアント（APサーバ）で処理するのが嫌いなので滅多に使わないけれど、他の人が作ったモノをチューンするときはよくやります。

今日は、免許の更新で時間があるので、さらに追加。

昔、oo4oはフェッチサイズ100がデフォルトだったような気がします。
その頃は、64kのフレームリレーでC/Sの仕組みを作っていました。

64Kの環境で検索して1万レコードがヒットしても、セッション・サーバカーソルを維持して、スクロールされるたびに .Next みたいな処理にします。
ですから、画面の大きさによって、フェッチサイズを調整しながら処理していました。印刷のときは限界までフェッチサイズを大きくするとかね。

DBとのセッションが維持できないWEBシステムではページングするか、全件読み込むかしかない。多分、フェッチサイズが10と小さくなっているのは、ページングすることを前提に考えて、SQL側でOffset（PostgreSQL）、TOP（SQLSERVER）、ROWNUM（Oracle）などで絞ってないときに無駄読みさせないため処置だと思う。

私がJDBCを設計してもそうするけれど、バッチ処理とか、帳票印刷ではPGが調整すべきですね。

64kでリッチクライアントというような（グリーン画面なら全然問題ないけれど）、苦しい時代を経験していると体感的に分かるのですけれど、若い人はスタート時点からメガ単位ですから、体感的に直感的に分からないでしょうね。
いや、昔から全然気にしてない人も大勢いたけどね……。

生島さん、おはようございます。

Merge文が、いまいち浸透しない（私の感覚です。）のも
エラー処理や、進捗が分からないという理由なんでしょうかねえ。

ちなみに、私のアプリ開発における大前提は、
SQLは極限まで減らす方向ですので、
極力一発（もしくは一定量でCOMMIT またはBULK）
に一票です。

SQLが巨大になりすぎて、実行計画の作成に時間がかかったら
ループを考えますけど・・・。

ronさん、失礼。

アプリからというからクライアント処理かと思ったら、コードはPL/SQLですね。

確かにロックのために取得したモノを使わずに一括処理すると無駄が発生します。
SQLの繰り返しとどちらが無駄が大きいかというと、レコード件数などにより微妙で、一概には言えません。

基本は一括処理の方が速いけれど、要件によっては……微妙です。
ですから、コメントでも回した方が早いときもあるし、遅いときもある。
みたいな話になっています。

JDBCは関係なかったですね。
失礼。

> 生島 さん

こんばんは．
すみません，書き方が紛らわしかったですかね．

yHiro さんが提示してくださった，会計システムのバッチ処理事例の続きのつもりで書きました．「アプリ」は「バッチ処理のアプリ」です．

http://el.jibun.atmarkit.co.jp/g1sys/2010/01/post-6319.html#c32063627

（たぶん，他システムからの連携データの入力じゃないかな）

> 確かにロックのために取得したモノを使わずに一括処理すると無駄が発生します。
> SQLの繰り返しとどちらが無駄が大きいかというと、レコード件数などにより微妙で、一概には言えません

ロックもそうなのですけど，この場合，むしろエラーチェック（入力チェック）が判断の分かれ目になると思います．入力チェックを SQL 一発でやるか（やれるか），カーソル・ループでやるか．

入力チェックをカーソル・ループでやるのなら，処理全体をひとつのカーソル・ループにまとめた方が無駄がないかと思います．

また，データ量に関して，少なくとも，処理が 1 時間以上に及ぶのなら，処理進捗と中断/再開の機能は必須だと考えています．

処理を開始したが，いつ終わるかわからない，中断もできないでは，運用担当者は開発者に殺意を抱くことでしょう（笑）．

> JDBCは関係なかったですね。

バッチ処理ですので，DB サーバ上で動かすもの，と考えていました．Java / JDBC でやるにしても，NIC は介さずに，IPC 接続（共有メモリ上でプロセス間通信）が良いですね．

> エントリーポート さん

こんばんは．

> ちなみに、私のアプリ開発における大前提は、
> SQLは極限まで減らす方向ですので、
> 極力一発（もしくは一定量でCOMMIT またはBULK）
> に一票です。

カーソル・ループであれば，COMMIT 回数を減らす，配列 INSERT にする，といった対応は，簡単にできると思います．全件で COMMIT 1 回とすることもできます．それこそ，「微調整」の範囲じゃないですかね．

逆に，SQL 一発になっている入力処理を，COMMIT 回数を増やせ，カーソル・ループ に直せ，といわれたら，簡単にできますかね？ もちろん，入力チェックも含めてです．

SQL 一発で出来ている入力処理が，システム稼動当初は問題なく動作していたが，その後のシステム機能拡張，データ量増大で動かなくなった，という事例には何度か遭遇しています．

しかも，こういったことは，システムの処理量がピークに達した時に起きます．つまり，ユーザ業務の繁忙期です．会計システムであれば，決算期が該当するでしょう．ユーザ業務の忙しさが頂点に達したときに，システムが停止するわけです．

ユーザは怒り心頭で，「今すぐ直せ，1 時間以内に直せ」などと言ってくるでしょうね．

ron様 こんばんは。

んー、できますね。

SQLに条件を追加して、その条件分ループさせればできるでしょう。
COMMITの増減もその中でやるか外でやるかですね。
カーソルループにするかは微妙ですが、すること自体は簡単です。
入力チェックは、そもそも外に出てますし。

この修正でも、ものの数行追加するだけですね。微調整の範囲です。

頑固にSQL派です。

ていうか、ron様は別に頑固にループ派というわけではなさそうな？
経験値の差ですかね？？？ ron様 ＞ 私 かなってことですよっ。
(ケンカ売ってるみたいで、超ドキドキしてます･･･)

できることならリリース前に経年テストはしときたいですね。

あ、RDBMS自体のバグに出くわしちゃったら1時間じゃ直りません。
ごめんなさい。

皆さん、おはようございます。

> SQLに条件を追加して、その条件分ループさせればできるでしょう。
> COMMITの増減もその中でやるか外でやるかですね。

COMMITするまでの処理の大きさを調整するだけなら、区分で回すとか、支店単位で回すとか、ってのが多いですよね。

私は、好きに設計できるときは基本的にトランザクション単位は避ける。
事前のチェックが一括でできるように

http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-af96.html

にあるようなスカラー関数を作ることが多いです。
負荷テストは予想されるMAXの倍ぐらいでやっておきたいね。

トランザクション単位でやると、テストが一連の流れでないとできないけれど、一括処理なら、SQL毎にテストができる。

バッチ処理で20個のSQLがあるとすれば、処理単位でログを出しますからMAX20のプログレスバーは出せますしね。

でも、ケースバイケースですな。

宝春さん＞
回答、ありがとうございます。
他にいうこと、なくなっちゃった。

ronさん>
宝春さんと同意見です。

> 宝春 さん
> エントリーポート さん

こんばんは．

> んー、できますね。
> SQLに条件を追加して、その条件分ループさせればできるでしょう。
> COMMITの増減もその中でやるか外でやるかですね。

例えば，50 個の入力テーブルから，100 個の出力テーブルへと，
INSERT ... SELECT しているとします．
（つまり，100 個の INSERT ... SELECT が並んでいる）
簡単にできますかね？

追加する条件句を全て同じにすることはできない，という前提でお願いします．

つまり：

　SELECT * FROM 入力テーブル1
　WHERE 入力テーブル1.分割項目 = 分割値;

　SELECT * FROM 入力テーブル2
　WHERE EXISTS(
　SELECT 1
　 FROM 入力テーブル1
　 WHERE 入力テーブル1.キー = 入力テーブル2.キー
　　AND 入力テーブル1.分割項目 = 分割値);

　SELECT * FROM 入力テーブル3
　WHERE EXISTS(
　　SELECT 1
　　FROM 入力テーブル2
　　INNER JOIN 入力テーブル1 ON
　　入力テーブル1.キー = 入力テーブル2.キー
　　AND 入力テーブル1.分割項目 = 分割値);

　．．．

など，色々な関連パターンがある，ってことで．

また，夜間バッチ処理の入力内容はすべてロールバックされていることになりますので，修正ミスをした場合，やり直す時間はない，と考えてください．

例えば，データ量の見積もりを誤って，1 時間後に処理がストップ，その後 3 時間のロールバック処理，となると，ジ・エンドです．

> ていうか、ron様は別に頑固にループ派というわけではなさそうな？

あ，もちろん，絶対ループにすべし，と考えているわけではないですよ．
最後は，ケースバイケースになる，ということは，むろん承知してます．

ただ，WRITE に関しては，ループの方が汎用的じゃないのか，SQL 一発の方が使える場合を選ぶのではないか，という主張です．

READ なら，無条件に SQL 一発でよいと思いますけどね．

> 生島 さん

こんばんは．

> COMMITするまでの処理の大きさを調整するだけなら、区分で回すとか、支店単位で回すとか、ってのが多いですよね。

データ量をうまく等分できる組合せを見つけるのが，難しくないですか？
現実のデータって，結構偏ってますよね．
例えば，大都市の支店でデータの 8 割 を占めているとか．

2 等分までなら，簡単にできるでしょうけど．
3 等分, 4 等分，と等分する数が増えてくると，だんだん難しくなってきそうです．

> トランザクション単位でやると、テストが一連の流れでないとできないけれど、一括処理なら、SQL毎にテストができる。

トランザクション単位でも，サブルーチン化しておけば，テーブルごとに分割してテストはできると思います．

PL/SQL なら，Java などと，ほぼ同じ感覚で，ユニットテスト（？）できると思いますが．

> バッチ処理で20個のSQLがあるとすれば、処理単位でログを出しますからMAX20のプログレスバーは出せますしね。

バッチ処理の場合，時間あたりの処理件数と，終了時刻を知りたい，ということが多いと思います．

前者は，処理が問題なく進行しているか確認するためです．統計情報が壊れている，他プロセスが CPU を使っている，ハードに障害箇所がある等，問題発生の前兆として，処理が低速になる，というのはよくありますので．

終了時刻については，運用担当者が，上司から「いつ終わるか？」と聞かれた際，答えられるようにするためですね．

プログレスバーは，むしろ無い方がよいと思います（笑）

こんばんは。
yHiroです。

ronさん:
私の言いたかった事を綺麗に纏めて頂いて有難うございます････自分の表現能力の乏しさに反省です。

基、
やはり、私の場合は先に書いた様にUIは一発SQL重視、バッチはCursor～Loopが主です。
処理に関わるデータボリュームの関係が主ですが、エラー対処後のReRUNを考えると特に夜間・月次処理などの投げっ放しは、細かなエラーログと簡単なReRUN手段を用意しておかないとトラブル時に早期対処がしにくくなりますので。

UIは対象の画面で確認できるのであれば、早期対処はしやすいですし複数レコード参照画面であっても、画面からの検索条件がユーザに問い合わせられるならバッチ処理のトラブルよりも対応が出来ます。

すべて私の経験談ですが。

あ、もちろんバッチ処理でも単発SQLでもいいところはやってしまいますよ。

皆さん、おはようございます。

多分、分かってやる分にはどちらも正しいと思います。

テストについては、当然、ループしてもそれぞれストアドプロシージャにするのでしょうが、引数に入れにくいのよね。

区分とか支店とかで回すとしても等分にこだわる必要はなくって、最大の処理量が小さくなったら良い。

リランも10万件中、25400件目のエラーを検出してっそれを直して、25400件目からリランというのは個人的には嫌いですけれど……。
フラグでやってもいいのですけどね。

エラーログはいずれにしても必要だから、私はいつもそちらのパターンで設計するかな。遅くなる処理がないことはないのですが、大抵はループするよりも、10倍前後速くなるので、1時間なら6分ぐらいになる計算。
障害対応も処理時間の10倍の差は大きい。
ケースバイケースですけど。

結局、議論ができればいい。
初級シスアドレベルが混じったら「できないから選びようがない」ということになるから、それを避けたいだけなのです。

ronさん、こんにちは。

>例えば，50 個の入力テーブルから，100 個の出力テーブルへと，
>INSERT ... SELECT しているとします．
>（つまり，100 個の INSERT ... SELECT が並んでいる）
>簡単にできますかね？

>追加する条件句を全て同じにすることはできない，という前提でお願いします．
単純にＳＱＬの数が多い場合は、動的ＳＱＬにして実行する場所を
１箇所にまとめる方向で考えるので、方式の変更は
簡単だと思います。

条件句の違いは、管理テーブル作って、そこに入れておくと
あんまり問題にはならないと思いますし。
（その場合、どんなＳＱＬを実行したか、
　 ログにちゃんと書いておく必要がありますが。）

それでも、パターンを見つけ出しにくい、
複雑になりすぎる場合にループを考えます。

エントリーポート様

先日は、回答を奪ってしまってごめんなさい。

ron様

いずれにしても基本的に要件をレコード単位には考えません。
I/Fの処理だったらあるでしょうけど、設計の段階で切り分けて
おきますね。

数時間かかる処理のいつ出てくるかわからないエラーを見つけるより
数分で終わるようにして全件見た方がラクです。

> 生島 さん

こんばんは．

> 区分とか支店とかで回すとしても等分にこだわる必要はなくって、最大の処理量が小さくなったら良い。

その最大の処理量がわかるか，ですよね．
何百万件なら確実に入るのか，を 100% 確信を持って答えられるか？
かつ，その最大処理量に合わせてうまく分割できるか？
かなり難しいと思います．

バッチ処理が停止している間，入力データは滞留しつづけますから，停止期間によって，分割する量は変わってきます．

例えば，ハードの故障であるのなら，修理・交換の時間を待たなければなりません．

確実にいえるのは，当日停止したなら，3 等分すれば間違いなく入るし，2 日後なら 5 等分，3 日後なら 9 等分ってことだと思います．

> リランも10万件中、25400件目のエラーを検出してっそれを直して、25400件目からリランというのは個人的には嫌いですけれど……。

ループでやっている場合は，確実に入力できる量に調整できますので，1 回で成功させられる可能性は高くなると思います．

> 大抵はループするよりも、10倍前後速くなるので、1時間なら6分ぐらいになる計算。
> 障害対応も処理時間の10倍の差は大きい。

「処理時間」には，ロールバックの時間も含めて考えるべきでしょう．1 回で成功させられなければ，SQL 1 発の方が時間がかかることになります．

> エントリーポート さん

こんばんは．

> 単純にＳＱＬの数が多い場合は、動的ＳＱＬにして実行する場所を
> １箇所にまとめる方向で考えるので、方式の変更は
> 簡単だと思います。

え，1 箇所で，実行時に 全 SQL 文を構築ですか？
（びっくり）

で，構築される SQL は確認せずに流すわけですか？
確認の手間を考えると，それで修正が早くなるとは思えませんが．
結局，構築される SQL 文を１つ１つ確認していくことになりませんか？

> 条件句の違いは、管理テーブル作って、そこに入れておくと
> あんまり問題にはならないと思いますし。

条件句そのものを，管理テーブルに入れて，実行時に構築する SQL に差し込む，ということですかね．

修正の手間は変わらない，というより，むしろ増えてるような．．．

> 宝春 さん

こんばんは．

> 数時間かかる処理のいつ出てくるかわからないエラーを見つけるより
> 数分で終わるようにして全件見た方がラクです。

数分で終わるかどうかは，データ量が，うまく入るサイズに，きっちり切り分けられているかどうかにかかってますね．

処理途中で，ロールバックがかかれば，数時間コースです．

> 宝春 さん

すみません．
今の論点に関係ないと思って，一旦スルーしましたが．

> いずれにしても基本的に要件をレコード単位には考えません。

レコード単位ではなく，トランザクション単位ですよ．
WRITE 処理でこれを考えないのは非常にまずいと思いますが．

データベース・データの整合性は考慮しないということに．．．

何度もすみません．
なんか論点がずれてますね．

もともとループになっている場合は，せいぜいコミット回数を変えるだけですから，修正の手間は考えなくて良いでしょう．1 トランザクションずつコミットしているのなら，そもそも，領域がパンクしたりしないわけですし．

パンクした場合の，修正の手間を考えなくてはならないのは，SQL 一発の方だけですよね．

宝春さん>先日は、回答を奪ってしまってごめんなさい。
いえいえ、本当に感謝しているので気になさらないでください。
逆に気を遣わしてしまったみたいで申し訳ないです。

ronさん>構築される SQL は確認せずに流すわけですか？
確認というのは、テストの事ですか？
テストなら、INとOUTを確認したらよいので、
方式の違いにより違いが出るとは思わないのですが。
それに修正の手間ですが、慣れの問題もあるのですが、
ずらっと、INSERTが並んでいるよりも、
私はこちらの方がやりやすいと感じています。
（好き嫌いもあるので、感覚的なことしかいえないのですが。）

多分、みなさん、ケースバイケースで選択されているのでしょうけど、
ループ：確実なCOMMIT優先
　　　　リランは簡単。
SQL一発：速度優先
　　　　 ただし、ある程度のグループで分割も可。
　　　　 フラグ等で一定量のCOMMITも可。
　　　　 リランは一手間必要。
という認識であってるでしょうか？

で、私の経験では、バッチ系はよく夜間中に終わらないと
いけないという要件が多かったので、速度優先に考えがなっています。
確かに性能重視でないなら、ループのほうを選択するかもしれません。
でも、なかなかそんな仕事に当たらないんです。

こんばんは。

えーと、飽きてきたので、そろそろ止めたくなってきました。

ron様

> 数分で終わるかどうかは，データ量が，うまく入るサイズに，
> きっちり切り分けられているかどうかにかかってますね．

じゃあ、大丈夫ですね。
いや、サイズも考慮しますけど、「そこから」設計するわけじゃ
ないです。

> WRITE 処理でこれを考えないのは非常にまずいと思いますが．
> データベース・データの整合性は考慮しないということに．．．

すみません、どういう要件をどう設計して、どういう状況を
想定しておっしゃっているのか、わかりませんでした。

Zzz...

皆さん、こんばんは。

初級シスアドと違って（笑）多分、個別の事情によって大きく違うと思います。
個人的には夜間バッチに毎日付き合う訳ではないので、とにかく早く終わらせたいという思いはありますから、ほぼ、一括処理にします。
リランを考えても、普段、1時間の処理が繁忙期に2時間になって、そのときにトラブったら……、リカバーできても2時間掛かる可能性があり……。
ということは、素で4時間掛かる可能性があるわけですよね。

レコード毎の処理をベースに考えて、これは簡単だから一括処理という人とは逆で、基本、一括処理を考えてどうしようもないとき、＆ どうしてもループする方が早いと思うときループする？

なんにせよ、ケースバイケースで、ここに書けるレベルでは答えが出ないと思う。

またまた、こんばんは。

> で、私の経験では、バッチ系はよく夜間中に終わらないと

私がコの業界に入って半年くらい経った頃(７年前くらい)のことですが
ループでまわしている処理(VBで全件クライアントでループ処理)の保守を
やらされて、バグだらけで2時間経ってから間違いを見つけてまた2時間･･･を
延々繰り返して、朝まで付き合ってたことがありました。

待っている間ひまだったので、SQL一発で書いてみたんですけど
「あのー、SQLで書いたら8秒で終わっちゃったんですけど･･･」
って当時のSEの方に言ったらスルーされました。

懐かしいなぁ･･･(遠い目)。

皆様

こんにちは。
yHiroです。

VBやJava等のクライアント側やAPサーバ側で2時間ループは以ての外ですね。
こういった言語は基本的に画面表示などプレゼンテーションに使用するのがベターと考えているのでループでデータを加工して画面表示する場合はDBサーバ(PL/SQLなど)で加工・ワークテーブル投入して処理結果を画面側に返してってやりますね。

巷にあふれているRADツールっていうのでしょうか、それを使用した案件で検索条件によって数万件になってしまう画面。何が何でもツール側でループ処理しようとしているメーカー技術者とか居ましたねぇ･･･。
自社のツールに誇りを持っていたと言うことなのかもしれませんが、顧客には理不尽だなぁと思いましたねぇ。

皆様，こんばんは．

ま，あまり続けても仕方ないので，そろそろ終わりにしますかね．
お付き合いいただいて，ありがとうございました．

連携のような，バッチ処理の場合，入力データは常に増加し続けてますので，1 日経てばデータ量は倍に増えます．SQL 一発の場合，リランをやる時点によって，うまくデータ量を分けることはできないでしょうね．それは私も過去何度も検討して，駄目だと結論を出してます．

後，性能ですが，私の 5 年物のノート PC で実験してみました．
RDBMS は，Oracle 10g R2 XE です．

8 万件程度のテーブルから，1 ～ 10 個のテーブルへと INSERT した結果です．
(1) がテーブル数，(2) がカーソル・ループから INSERT の処理時間（秒），(3) が INSERT ... SELECT の処理時間（秒）です．

(1)| (2) | (3) |(2)/(3)
------------------------
1 | 8.55 | 1.55 | 5.52
2 | 14.21 | 3.96 | 3.59
3 | 15.46 | 2.51 | 6.16
4 | 21.24 | 4.29 | 4.95
5 | 34.79 | 6.75 | 5.15
6 | 47.34 | 8.53 | 5.55
7 | 42.75 | 9.69 | 4.41
8 | 46.15 | 12.81 | 3.60
9 | 82.88 | 17.93 | 4.62
10 | 94.78 | 24.17 | 3.92

平均すると，性能差は，5 倍ってところですね．

生島さんの方式ですと，1 回ワークテーブルに INSERT ... SELECT しますので，出力先が倍になって 2.5 倍，入力チェックも同様だとすると，さらに倍で，1.25 倍．

性能差は，INSERT ... SELECT だと，1 時間かかる処理が，カーソル・ループだと，1 時間 15 分になる，という程度でしょう．

また，一般的な傾向として，テーブル数が増えれば，差は縮小してくると思います．

ronさん、おはようございます。

単純なら10倍前後になったと思うのですが……。メモリーとかチューニング次第ですので何とも言えません。REDOログのサイズとか、待機とか、その辺のチューニングをしっかりすると10倍ぐらいになると思います。

> 生島さんの方式ですと，1 回ワークテーブルに INSERT ... SELECT しますので，
> 出力先が倍になって 2.5 倍，入力チェックも同様だとすると，さらに倍で，1.25 倍．

エラーログ用のテーブルをワークと言っただけで、基本的にワークは使わないですよ。
入力チェックはエラーのみのINSERTになるから倍にはならないです。
エラーはループでやってもログに書くでしょうから、やっぱり一括の方が速いです。

入力チェックで、何らかのテーブルアクセスが発生するとすると、ループで処理するともっと遅くなります。
そういう細かい制御のためにループを選ぶのですから、普通、入力チェックでSELECTしなければならないことの方が多いですよね。

ただ、入力チェックの内容によっては、一括でやると遅くなるパターンも存在します。
APサーバやクライアントから回してはいけない。というのは絶対と言い切れますが、（また別サーバ云々とか絡まれるかも知れませんが）DBサーバ内処理の場合ケースバイケースですけれど、基本的には一括の方が圧倒的に速いので、まず一括を選んでどうしようもないときにループというパターンで検討します。

> 生島 さん

こんばんは．

> エラーログ用のテーブルをワークと言っただけで、基本的にワークは使わないですよ。

あー，そうでしたね．すみません．
何をやっているんだか．．．
いつの間にか，昔みたコードに置き換わってました（苦笑）．

八つ当たりですね．これじゃ．
皆様，申し訳ありませんでした．