解答例１、２はなぜ悪い？

汎用機（何億もするコンピュータ）で Ｃｏｂｏｌ などで組むなら、解答例２でも何の問題ないでしょう。

しかし、解答例１、解答例２はただ、仕様書・プログラムが長くなるだけが問題ではありません。

データベースとのやり取りは、ミドルウェアというサーバとクライアントの仲立ちをするソフトが行います。
（ＪＤＢＣ、ＯＤＢＣ、ＡＤＯなどなど）

データベースを利用するシステムは次のようになります。

　　　　クライアントソフト
　　　　　　　↓↑
　　　　ミドルウェア
　　　　　　　↓↑
　　　　データベース（エンジン）

クライアントソフトは場合によっては、Tomcat などのアプリケーションサーバの可能性もあります。
ブラウザ（アプレット）が直接クライアントになる可能性もあります。
たとえば、オラクルをサーバ上で SQLPlus を利用する場合でも同じです。
SQLPlusはクライアントソフトで、オラクル社のミドルウェアを使っているのです。

ですので、データベースを利用する場合は、必ず、上の構造で処理されると考えてください。

これらを少し分かり安く、文房具の出荷工場と、文房具店という構造で説明します。

　　　　クライアントソフト ＝ 文房具店

　　　　ミドルウェア ＝ （出荷工場の）営業マン

　　　　データベース ＝ 出荷工場

となります。

ちなみにＷｅｂシステムの場合

　　　　ブラウザ ＝ 文房具店

　　　　アプリケーションサーバ ＝ 商社

　　　　ミドルウェア ＝ （出荷工場の）営業マン

　　　　データベース ＝ 出荷工場

となりますが、商社と出荷工場の間が遅くなる原因です。

文房具店では、新入学の季節を迎えたので、鉛筆１ダースと消しゴム、筆箱、をセットにしてラッピングして１０００セット販売することになり、営業を呼びました。

以下の手順でオーダーします。

　　　　鉛筆の箱の注文（ＳＱＬを書く）

　　　　鉛筆を１本の注文（ＳＱＬを書く） × １２回

　　　　箱に詰め込む

　　　　消しゴムの注文（ＳＱＬを書く）

　　　　筆箱の注文（ＳＱＬを書く）

　　　　ラッピング作業

これを１０００回繰り返し。

　　　　営業マンは注文書（ＳＱＬ）を受け取り、出荷工場へ走る。
　　　　工場では注文書に間違いがないか確認する（オプティマイザという機能が担当する）
　　　　注文どおりのものを営業マンに手渡す。
　　　　営業マンが文房具店に品物を届ける。
　　　　次の注文書を営業マンに渡す…。（繰り返し）

結局、営業マンは１５０００回、文房具店と出荷工場を往復することになります。

この文房具店は余程おかしい人か、お客の立場を利用したイジメかどちらかですね（笑）

笑い話ではなく、解答例２はこんなシステムになってしまいます。
（意味が分かったら、仕様書を見た瞬間に絶叫してしまう私の気持ちが少しは分かるかもしれません）

解答例１は鉛筆を箱で持ってくるので、４０００往復に減りますが、根本的に遅いことには変わりません。
世の中の大半のシステムは、こんな処理をやっているわけです。
結果的には、クリックしたらコーヒーを淹れてゆっくり出来るほどから、一晩かかるぐらい遅いプログラムが出来上がることも多いです。

別のプログラムから、別のプログラムを呼び出すのには、非常に厳密な手続きが必要になります。
また、多くの場合、出荷工場（データベースサーバ）と文房具店（クライアント）または、商社（アプリケーションサーバ）は別のマシンになりますので、さまざまな通信処理が行われ大変遅い処理になります。

上の例では営業マンが走る部分で、オーバーヘッドと呼ばれるものです。
ハードウェアの性能にもよりますが１回で、0.005～0.05秒ぐらいあるかもしれません。

0.05秒って気にするほどのこともないって思いますか？
『そんな考え方だからメダルが取れないんだ！』じゃなくって（笑）

ちょっとしたシステムなら、１万件ぐらいのデータを処理することはざらにあると思います。
もし、１件の処理のために１５回もＳＱＬを実行する処理があれば、クリックして２時間は、フリーズしたかのようになってしまいます。
月次処理で１０万件処理が必要だったら、２０時間かかってしまいます。
0.05秒って、コンピュータにとって大変遅い処理なんです。

また、注文書の確認、これはオプティマイザがＳＱＬから作業手順書（実行計画という）つまり、内部仕様書を作成する作業ですが、これにも時間がかかります。
このように遅い原因が重なると、もう、どうしようもなくなるぐらい遅くなります。

遅いから修正してと要望を出すと、その対策は…。

ＶＢ作ってみたら遅かったのでＣ＋＋にしてみましたとか。
（ラッピングの作業が速くなるだけです。）

ネットワークを速くしましたとか。
（営業マンの車をカローラからフェラーリしただけですが、この場合、費用はお客様負担の場合がほとんど。）

工場を最新式に、文房具店を最新式に…。
（ハードの問題じゃないって…。）
などなど、見当違いな修正しかできません。

もし修正するとしたら、詳細設計とプログラムを捨てて１から作り直ししかないというのは、分かっていただけると思います。
しかし、システム会社として、プログラムを納めてから、遅いのはプログラムの構造が悪かったためなので作り直します。

と言うことはほとんどの場合できません。

こんな１から作り直さないといけないシステムを、倍以上の費用と時間を掛けて作ってしまう、その原因は、営業やコンサル、ＳＥが、お客様との打合せの時点に頭に浮かんだ処理フローにあるわけです。
『何回も営業マンが往復する構造』をほとんど全員が想像し、声に出すまでもなくその方針が確定してしまいます。

営業やコンサル、ＳＥが、ユーザでも出来るべきＳＱＬを理解しないで、平気で Oracle や SQLServer の提案をするからです。

『何回も営業マンが往復する構造』を実現するための見積もりを行う。
結果、仕様書の量もプログラミング量も多くなるため、ベリ～えくすぺんしぶ！なシステムになるのです。

そして、予定通り完成しても、データ量によっては、使い物にならないパフォーマンスになることも確定しています。
受注前に失敗か成功か決まっているわけです。

処理フローが打ち合わせの時点で浮かぶなら、ＣｏｂｏｌやＰＬ／１などの提案にすれば、最高のシステムが組めます。
派手な流行を追いかけず、自分達に出来ることでまっとうな提案をすれば、お客様に迷惑をかけることも、不幸な部下を作ることもなくなります。

ＳＱＬを使うなら、営業マンに注文書（ＳＱＬ）を渡すときに、全ての材料が１回で届くように注文書を書く。
こうすれば効率的なのは、中学生でも分かりそうな話です。

私の『ＳＱＬを１回にしようよ』という変人扱いまでされるこだわりですが、一般的に見れば、中学生でも分かるぐらいごく普通のことしか言ってないのです。
逆に、解答例１のような構造でも、何も違和感を覚えない人は、業務効率を上げるためのシステムを作るという仕事をしていながら、中学生でもしないような非効率なプログラムを作っているわけです。

無意識にそんな指示を出しているのです。

『ＩＨクッキングヒータの横にカマドを作る』というたとえが大げさではないことも分かると思います。

ＳＱＬを使うシステムを提案するなら、上級ＳＥが素人にも分かるＳＱＬを十分に勉強する必要があります。
時間がないことは重々承知していますが、それでも、あなたが変わらないからスタートラインに立つ前に『何回も営業マンが往復する構造』が確定しているのです。

言語はプログラマが分かればよい。では、これまで書いたとおり、解答例１までが限界です。
あなたが変わらなかったら、あなたの部下は忠実に、中学生でもしないような非効率なプログラムを作ってきます。

このような話を書くと『うちはJavaでMVCモデルのとおり組んでるよ』という話も聞こえてきそうです。
でも、Been（EJB）の中で、ループまわしていたら同じことですよ。
商社のパターンです。

一度、ソースを見直してください。

あなたが、上級ＳＥなら、最初の問題を解いてみてください。
あなたの部下に、問題を出して試してください。
紙に書くように言うと、スペルミスとか枝葉末節に気をとらわれるようになるので、紙を見せて口頭で答えさせる方が良いかもしれません。

普通にこうあるべきと考えている技術者なら、紙に書いて５～１０分、口頭ならほとんど即答できると思います。

この問題が解ければ、他にＳＱＬで注意すべきところは、ほぼ分かっているとみなしてよいと思います。

ＳＥの５０％、プログラマの３０％が解答例３の答えを出せれば、プロジェクトの成功は間違いない。
私にとって夢のプロジェクトです。

ベリ～えくすぺんしぶ！な見積もりを通して人海戦術で何とかする。
営業マンの腕がよければそれも可能でしょう。
そんなことを続けていたら、長い目で見たらとんでもないことになると思います。

じゃあ、私と同年代、それ以上の方がやってきた手続き型のプログラムは無意味なのか？
そんなことはありません。

今、ＳＱＬが出来ない技術者が多いからこんなことを書いていますが、ＳＱＬしか出来ない技術者ばかりになると、多分、私は『手続き型言語を出来るようになれ！』と言い出すでしょう。

勝手なわがままオヤジですね～。

いい加減くどいですが、そういうことを次回に。

＜続きはもっとテクニカルに＞