SQLのイメージと他の言語のイメージ

　Twitterで検索したりすると、SQLが分からないという人が相も変わらず非常に多い。おそらく、分からないという人は文法から入っているよね、いや、ほぼ間違いない。しかし、遠回りに見えてもイメージから入るべきです。

　初めのうちは、AccessなどGUIでSQLが書けるツールを利用して、FROM句だけを徹底的にやってみてはどうかと思う。

SQL以外の言語はボトムアップ

　できない人のほとんどは、文法を元にバラして考えているから出来ないし、理解に時間が掛かる。他の言語をやった後に、文法から理解しようとすると、あまりのギャップに苦労することになる。挫折する人のほとんどが、そこで挫折してしまうようです。

　他の言語は、プラモデルを組み立てるかのごとく作っていきますから、ある程度の規模になると設計書が必要であったりします。SQL以外の言語をやっているときは積み上げ型（ボトムアップ）の思考回路になっています。

　例えば、プラモデルはパーツにバラして、それぞれに色を付け、バリ取りをして、パーツを完成してから組み上げていきます。色を塗るテクニックであったり、バリを取るテクニックだったり、様々な細かなテックニックが必要です。

　言語に置き換えると、全体像を想像することはやはり重要ではあるのですが、SQLに比べると文法の重要度は高くなりますから、SQL以外の言語を覚えるときはある程度文法をやらざるを得ないので、文法から考えるクセがついている人が多くいます。このクセを抜かないとSQLを理解するのに非常に時間が掛かるのです。

SQLはトップダウン

　SQLは粘土細工のように組み立てます。塊から削り出すトップダウンのイメージです。

　手順としては、まずはFROM句で外形になる材料（テーブル）を集めます。

　JOINでひっつけ、大まかな外形を整えます。

　後は、WHERE句などの条件を付けてひたすら削り、SELECT句で整形します。

　条件を加え削る度に実行し確認する。削っている途中で間違いがあったときは、工程を元に戻しながら考えて行きます。

　考え方としてはトップダウンで、先ず全体像のイメージがあれば細かいパーツについて考える必要はありません。

　全体をイメージしてどう削っていくか、もちろん、最終の形状によっては削り出すことは非効率になることもあります。それが非効率か判断する能力も、全体をイメージしているか、削っていく過程を想像しているかによって違うでしょう。何よりも大事なことは全体のイメージを捉えること。細かいことは気にしないこと（笑）。

SQLは単独ではシステムが出来ない。

　出来上がった粘土細工はそのままでは使えません。そこに色を付けたり、可動部を作ったりする。つまり、ユーザインターフェースを提供するための言語は必要になります。つまりは、粘土細工職人は、プラモデル職人の手を借りることになります。

　全く逆の手法になるのですから、同じ人が担当するというのが無理があるのです。しかし、基本的に職域も考え方も全く違うのにもかかわらず、プラモデル職人の考え方で粘土細工職人の職域に入ってこようとするから問題が起きる。

　つまり、粘土細工でパーツを作ってから、プラモデルを作るのと同じ手法で作り上げてしまう。こんなやり方には無理があり非常に非効率です。パーツを粘土で作るコストと、組み立てるコスト。生産性と実行時のパフォーマンス、メンテナンスの面でもデメリットは非常に大きいのです。

　もちろん、「出来ないというのか？うちは出来ている」っていわれれば、その通りでしょう。効率の話をしているのですけどね。

　私は「インピーダンスミスマッチが何で問題になるのか？」理解できていません。インピーダンスミスマッチが問題と考える人は、片側の手法で完結したいと考える。そもそも「同じにできる」という間違った考え方を持っているのではないでしょうか？そもそも違うものですから、別々に考えれば何の問題もないはずです。

　どうしてもプラモデルとして組み立てたいのなら、最初から粘土細工を使わない NoSQL を選択すれば良いのです。RDBMSを選択するならばSQLは必須の技術です。