長々と読んでいただいてありがとうございました。
とりあえず、上級ＳＥの方に向けてのまとめを書きたいと思います。
１．ＳＱＬは今や必須の技術。
ＳＱＬは情報処理技術者試験（最近、実際に沿った問題が増えてよくなって来てます）を例に考えますと、Ｃｏｂｏｌなどの言語はプログラマ向け試験の選択問題です。
それに比べてＳＱＬは（簡単すぎる問題しか出ませんが）エンドユーザ向けの初級アドミニストレータ試験から、コンサル向けのシステムアナリスト試験まで、全ての試験区分で必修です。
つまり、情報処理技術者にとってはＳＱＬは必須のスキルなわけです。
繰り返しますが、外部仕様（基本設計）≒ ＳＱＬですから、プログラマではなく特に上級ＳＥ向けの言語です。
あなたが、オープン系（ＲＤＢＭＳ）にかかわるのであれば、営業でも、プロジェクトマネージャでも『今更、プログラミング言語など』という言い訳はすべきではないと思います。
覚えるのが嫌だったら、オープン系（ＲＤＢＭＳ）を使わなければ良いのです。
２．ＳＱＬを習得るには、処理フローを考えないことからはじめよう！
ああなたが、技術者として優秀であればあるほど、処理フローが頭に浮かぶことが邪魔して、ＳＱＬを習得するのは難しくなります。
嫌味でもなんでもなくＳＱＬを難しいと思うのは、頭がよすぎる証拠です。
ですが、元々優秀なあなたです。
ＳＱＬには処理フローがないということを頭に叩き込んでから、詳しい目の入門書を１冊読めば簡単に身につくはずです。
プログラマからＳＥ、コンサルへとステップアップするのと同じように、コンピュータ言語もステップアップしたのです。
同じやり方でやろうとしたら駄目です。
長々と書きましたが、言いたかったのはこの２つです。
もし、あなたがこんな深いリンクまでたどってきて、この長ったらしい駄文を読んでくれているならどんな人でしょう。
もし、良かったらメールください。
１．なにか分からないけど、うちのシステムが遅いのは、高かったのは、この理由かな？
と思っているユーザ。
２．同じことを思ってるけど会社のＨＰに書くかな普通。って思っている技術者。
３．しまった。今までカマドを作ってきてしまった。
今後は改めようと思っている技術者。
４．なんてことを言うんだ。と腹を立てている技術者。
５．良く分からないけど読んでみた、初級プログラマ・学生。
そんなところでしょうか？
１の人に向けて。
営業に行きたいな（笑）
もうすでに高いお金を支払っているでしょうし、作り直すのはずっと先の話でしょう。
そのころには当たり前になっていると思います。
残念。
もちろん、ご連絡いただければご相談に乗らせていただきます。
ただし、遅いのは表面を直しても無理です。
曙を速見もこみちに整形するぐらい大変です。
残念ながら作り直ししかないです。
２の人に向けて。
だから深いリンクに置いているのですが、のっけから飛ばしてるからね。
『ストアド使えよ！』とか、もちろん分かっているけど、今は言わないでね。
笑って許してください。
３の人に向けて。
がんばってください。
あなたのような人が１人でもいれば、私も書いたかいがあります。
４の人に向けて。
あなたが４の立場なら、部下に『最低、基本情報処理技術者試験は２年以内に合格しなさい』とか言ってませんか？
部下に『基本情報処理技術者試験は２年以内に合格しなさい』とか言うんですから、あなたがＳＱＬを分かって当然なんです。
オブジェクト指向とか、そんなものは概要がなんとなくわかっていれば十分です。
しかし、要件定義、外部仕様を書くために、ＳＱＬの理解は必須のスキルなのです。
嫌なら Ｃｏｂｏｌ など、ＳＱＬを使わないシステムをやるしかありません。
くどいな。
５の人に向けて。
カマド作り指示をするリーダの元で、ＳＱＬを覚えても、使うところはほとんどないでしょうし、あなたが何を言ってもプロジェクトの方針は変わらないでしょう。
でも、来たる日のために勉強しておきましょう。
あなたが上級ＳＥになるころ、必ずや大きなアドバンテージになるはずです。
Ｊａｖａを覚えても、その後、ＡＳＰの案件しかなければ、力を発揮する場はなくなりますが、ＳＱＬはどちらでも利用するものなのです。
最低限のスキルとして、ＰＨＰなどのスクリプトを含め、手続き型言語（要はＩＦやＬＯＯＰが存在する言語）を１つは経験して、処理フローが分かるようになる必要があります。
その後は、意識してＳＱＬの技を磨きましょう。
ＳＱＬが一番幅が広く、一番息が長い技術になると思います。
（勝手な予想ですが、ここまで読んでくれれば分かると思います）
ちなみに、ちょっとアジりすぎだと思います。
正直に言うと、最初の問題を５分で出来たら、ＳＱＬプログラミングは相当なものです。
入社試験に使っていたのは、解けると思ってではなく悪あがきの過程を見たいからです。
悪あがきの跡には、その人の思考ルーチンが残りますからね。
これぐらいアジると、出来るやつは出来るようになるのよ。
（アジるって古い言葉なので、若い人は分からないかもしれませんね）
そういう経験は強いですよ。
次に新しいものを見たときの吸収力が違ってきます。
へこたれる人は、今後も、どんどん新しい技術が出てくるのについて行けないですよ。
余談ですが、新しいもの（言語・技術）に出会ったときに、小さい方は見たら駄目です。
大きいほうから見てください。
たとえば、ＳＱＬには、SELECT、INSERT、UPDATE、DELETE文がある。
なんてことは小さなことなのです。
ＳＱＬなら、ループなどのフロー制御を書かなくても目的が遂げられるように開発された言語。ってことが一番大事なわけです。
この大前提を見失って、瑣末な『ＳＱＬの記述方法』を勉強しても、本質は身につかないです。
巷の教科書は『ＳＱＬの記述方法』に重点をおいて書かれていますが、大前提は最初にちょっと書いてあるだけですからね。
大前提が分かっていれば『ＳＱＬにはフロー制御がないからクライアントでフロー制御』なんて馬鹿げたことになるはずがないと思います。
慣れたら、最初の問題程度のことは、お客さんの話を聞いた瞬間に浮かぶようになると思います。
そんなに難しくはないです。
次からは、内部仕様を書くＳＥ、プログラマ向けのテクニックについて。
<< 第２２回目 「SQLについて（安い、且つ 速いシステムを作るには) 解説３」 | | 第２４回目 「データベースのインデックスについて」 >>
コラムの全インデックス
