「SQLが会話のペースでできるようになる！」わたしの勉強法
これができれば、SQLが会話のペースでできるようになる！（かも？）という、わたしの勉強法です。長いけれど、平易に書いたつもりなので、読んでいただければ幸いです。
■ まずはプログラムの勉強法
わたしは裕福な家庭で育ったわけではないので、ファミコンも、ステレオも、ラジカセもなかった。
もちろんPCなんてなかった。
そんな小学生の頃、「中学生がゲームソフトを作って何百万儲かった！」なんてTVで見たのだろう。貧乏がイヤで仕方なかったわたしは「何百万」に即座に感化されて、雑誌（多分BASIC Magazineかな？）を立ち読みした。とはいっても、小学生の脳味噌でPCなしに雑誌を読むだけでプログラムが勉強できるわけもなく、「プログラムの前にフローチャートを書きましょう」と書いていたのだけが頭に残ったようだ。
それで、なんとなくプログラム、例えば、ゲームウオッチとか、インベーダーゲームとか、それ以外にも、ビデオの予約機能などを見ると、言語はまったく知らないのですが、とにかくフローチャートを想像するようになり、さらに、何でもフローチャートを考えるようになりました。
例えば、朝起きるときに、
寒くて布団から出たくない
→ あと5分
→ もう5分
→ もう5分
→ トイレに行きたくなった（割込処理という言葉は知らない）
→ でも、布団から出たくない
→ トイレに行きたい ……
突発的に「トイレ行きたい」が発生するのは、インベーダーゲームでボタンを押されたとき、ミサイルが出るのと同じか。
コンピュータは決まったことしかできないから、「トイレ行きたい」の他に、「親が怒ってくる」とか、「腹減った」とか、「TVから面白そうな音が聞こえてくる」とか、そういうパターンをすべて書いておく必要があるのか……。
（乱数という言葉だけは覚えていて）乱数で何分の1かの確立で用意した処理を起こせばいいわけだ。
（ループがあって、ブレイクの判断をしていて、という言葉は当時は知らないけど）整理したらフローチャートになるな。
でも、ゲームにしても面白くないな。
「トイレ行こ」
ってなことを考えたりしていたわけです。
わたしはそっちの才能がないようで、ゲームのシナリオはまったく思いつかなかったし、言語はまったく知らなかったのですけれど、正しいかどうかは別にして、何でもそんな風に考える癖が勝手についてしまったようです。
小学校高学年でそうなっていたわたしにとっては、ごく自然な考え方ですから、「みんなも同じように考えている」と、つい最近まで思ってました。
あまりにも周りと話が噛み合わないことがあって、自分の思考ルーチンを見直したところ、もしかして、「みんなはそんな風に考えてないのかな？」と思い至りました。社員に聞いてみると、「普通の人はそんなこと考えません」とのこと。
自分が異常だとはなかなか認められないのですが……。異常なのでしょうか？
それはともかく、アルゴリズムは小学校のときに体得していたようで、19歳でHP社のワークステーションを触るようになって、実際のプログラムを見たときに何をしたかというと、仕様書なんてない、コメントもほとんどない生のソースコードを見て、分岐、ループ、サブルーチン（笑）などを探して、頭の中でフローチャートに戻し、間の処理を想像しました。
インデントはちゃんとしてあったので、流れは何の苦もなくすぐに理解できました。
想像したフローチャートと、プログラムの実行結果から、このIFの後の処理は「×××の処理をしているはず」「つまり、×××の処理はこんな書き方をするんだ」と理解していきます。
全部の行の意味を理解する必要はないし、必要があればリファレンスを開けばいい。
ソース丸ごと見えているのでブラックボックスではないのですけれど、分からないところはブラックボックスとして判断して、とにかく全体をざっくりと把握し、自分の必要なところだけを見ていました。
分からないところはすっ飛ばせばいい、と考えていたおかげか、ブラックボックスを気にしない大雑把な性格だからか、オブジェクト指向はブラックボックスの組み合わせなので、違和感なく移行できました（毎度、苦労するのはツールの使い方の方ですね）。
そんなわけで、初心者がどんな勉強をするのか分からないのです。
もしかして、フローが浮かばない状態で「Hello World!」から始めるのでしょうか？ それで、プログラムができるようになるのかな……。
無意識で考えていることが違うということは文化が違うということですから、わたしには初心者の考えることは分かりようもないのに決め付けてはいけないけれど、プログラムができない人は、フローチャートらしきものも頭にない状態で、プログラムソースの1行目から見ていくとか、言語仕様を覚えることから始めたり、人間というオブジェクトを作るのが目的なのに爪クラスから作ろうとしているのじゃないかと思う。
そういう勉強方法よりも、最低限のアルゴリズムを理解することと、全体から見る考え方が必要なんじゃないかと思います。
わたしが子供の頃になんとなく身に付いてしまった、何についてもフローチャートにしてみるというのは、電車の中でも、風呂の中でも、寝る前でもできる頭の体操です。これが効果的な勉強法なのかよく分かりませんが、もしかしたら、効果があるかもしれません。
■ わたしがSQLを覚えたのは？
というわけで、小学生の頃に勝手に覚えたので、わたしはフローチャート（アルゴリズム）にするのはネイティブ（会話のペース）と言えます。オブジェクト指向も抵抗なくネイティブ並みです。
しかし、SQLを考えるときは、当然、今までとは思考を切り替えねばなりませんでした。
わたしはSQLは以下のように（本当はちょっと違うけど）ビジュアルで考えています。
テーブルごとにExcelシートを思い浮かべています。
- それぞれのテーブルを並び替えて、必要なデータを抜き出す
- ブロック単位でワークのファイルに持ってくる
- 結合処理
- グループ化のための並び替え
- 計算処理（同一データの間引き）
- さらに抜き出す
- 最後に並び替え
昔、この処理をDOS版のLotus 1-2-3で手作業でやっていました（複数のシートが扱えない頃は、横のエリアを使って……）。
これはDBEngineの処理そのものです。
わたしはこのような処理をLotus 1-2-3で手作業でしながら、「無駄やな～、なんか簡単に汎用的にできる仕組みにできないかな～」と、つまり「SQLみたいなものを作れないか」と思って、Lotus 1-2-3でマクロを書いたり（完成できなかったけど）していました。
ですから、SQLを知ったときに衝撃を受け、なんとしても習得したいと思ったためか、思考の切り替えは苦にならなかったのです。
しかし、結果的にプログラムを覚えたときと同じように、文法から入るのではなく、やりたいこと（SQLの実行計画）があってそれをSQLにするにはどうしたらいいか？ という勉強方法になりました。
最初はAccessのGUIで書いてたのですけれど、あくまでも処理のイメージを変換していたわけです。
■ 「SQL」わたしの勉強法
前振りが長すぎですが、SQLの勉強法についてです。
わたしは意識してやったものではないけれど、同じことをしたらどうでしょう。時間がかかるかもしれませんが、力が付くと思います。
というわけで、実践方法です。
まず最初に、例題を何か用意しましょう。できればHAVING句まで使っているSQLの設計書なり、要件定義なり、基本設計なりを準備しましょう（HAVINGは使ってないけれど、前のMartin Fowler氏のでもよい）。
それと、エクセルを用意します。
まず、結果用のワークシートを用意してください。次に、必要なテーブルをすべてエクセルのシートにする。レコード数は数十～百件でよいので、主キー順に作ってください。
さらに、インデックスがある場合、設定されているインデックスの数だけワークシートをコピーして、それぞれのインデックスの並び順にしてください。
データが用意できたら、要件どおりの結果になるように、結果用のワークシートに手作業で埋めてみてください。
あなたが行った手順こそが、ほぼDBEngineの処理です。
その処理を記述するのに、人間に分かりやすく、DBEngineにも分かるように作られたのがSQLなのです。
手作業でやれば判りますが、余程の間抜け（失礼）でない限り、自然に適切な並び順のデータ（インデックス）を使いますし、次の順で処理しているのが分かります。
SELECT（結果ワークシートの準備）
FROM（データの準備）
JOIN OR WHERE
GRUOP BY（グループごとに集計行を挿入して、挿入した集計行だけ見せるイメージ）
SELECT（計算処理）
HAVING
ORDER BY
そして、あなたが行った手順では、データの塊をコピーしてることでしょう。
つまり、その手順は集合理論で行われています。
このとき注意することとして、作業を行うときに、SELECT、FROM……ORDER BYのどの部分を処理しているか意識しましょう。
エクセルでは上下のレコードを参照する処理は簡単にできますが、SQLではOLAP関数でできる範囲でしかできませんから、GROUP BYの処理中以外は集計関数を使ってはいけません。
OLAP関数が理解できるようになったらその部分は使ってもいいですけど、エクセルの式や関数の引数には同じ行にあるもののみを使うようにします。
上下の計算が必要になるとき、つまり、結果用のワークシートの同じ行だけでは計算処理が終わらないときや、計算結果を再度処理するときは、それまでの結果を新しいワークシートにコピーして、その新しいワークシートを最終の結果用ワークシートとします。
つまり、今まで結果用と思っていたものは、サブクエリーになるわけです。他にも、作業用のワークシートが必要になったら、それらはサブクエリーになります。
上の条件でどんなに考えても、最終結果のワークシートができないときは、「SQLでは出来ない処理」ということになります。
次に、実際にエクセルシートを使うのではなく、脳内にエクセルシートをイメージ出来て（このとき名称を取るだけのマスターは当然無視する）手順まで考えられるようになれば、「集合理論で手順（処理）を考えられるようになった」ことになります。慣れたら会話のペースでできるようになります（学問的には集合理論じゃないとか、そういうツッコミはちょっと置いてください）。
あとは、
- 手順（処理） → SQL
- SQL → 手順（処理）
どちらも自在にできるようになるまで訓練です。
会話のペースでは手順（処理）までしか考えなくてもよいけれど（でも、考えたものを記憶するにはSQL文の方が効率的です）、サブクエリーがどの部分で、何個あって、その結果が何件ぐらいになって、インデックスが使えない検索がどれぐらいあって、最終の出力数が何件ぐらいになる……ということは、「パフォーマンスは××秒ぐらい」と予想までできるようになります。
ここまでできるようになれば、今までのプログラムは何だったの？ と思うぐらいに、爆発的な生産性＆パフォーマンスになるでしょう。
次にテーブル設計の訓練をすればいいけれど、おそらく自然にできるようになっているし、チューニングもできるようになったのと同じです。
このように考えると、Martin Fowler氏のSQLは不合理な手順（処理）になりますから、手順（処理）から考えれば、なかなか出てこないSQLになります。ところが同様のSQLは現場でよく見るのです。それらは、わたしの思考ルーチンでは出てこないSQLなので、どういう思考ルーチンで考えれば出てくるのか分かりませんでした。
とはいうものの、自分の思考ルーチンも無意識にやっているのでなかなか気づかないものです。しかし、この文章を書いたおかげで気が付きました。同時に、現場でよく見るSQLが、どんな思考ルーチンで考え出されたものなのかなんとなく分かりました。
手順（処理）を考えずに文法からSQL文を考えているでしょう？（そら、でけへんわ～）
文法としてはSQLは最低ですからね（笑）。文法から考えたら途中で投げ出したくなるのも無理ないですし、嫌いになるでしょう。文法から考えて書ける人はある意味すごいと思う。
わたしもSQL文の記述はなんとなく気持ち悪いし、手順はできているのに記述法が分からないってことも最初のうちはありましたから、勉強法としてSQL文の記述方法や文法から入ると、「よー分からん気持ち悪い記述」になって終わってしまうのは理解できた（のかも知れません）。
そういえば、総務や経理の方が、短時間にSQLを高いレベルで理解できることがあるのですけれど、普段エクセルでこういう手作業をやっていて、すでに脳内に集合理論での手順ができているから、と説明も付きました。
ともかく、やりたい手順が集合理論で脳内にイメージできていれば、それは必ずSQLで処理できます。
■ 文法について（面倒な人は飛ばして読んでください）
余談ですが、処理順はSELECTの後にORDER BYが来てるでしょう。
なぜかというと、計算結果でソートする必要があるときに対応するため、計算処理をするSELECTは先に処理されるわけです。
だから、ORACLEでORDER BYした後の行位置を取りたいとき、サブクエリーで先にORDER BYを掛けてから、ROWNUM関数を使うことになります（以前はサブクエリーでORDER BYはできなかったので使えなかったですよね）。
DBEngineは出力のORDER BYを一番最後にしますので、出力のORDER BYの結果を別のエクセルシートに貼り付けて（つまり、サブクエリー）、ROWNOM関数（エクセルではROW関数）を追加するイメージを持てば理解できます。
なぜ、上下の計算ができないかというと、ORDER BYまでは並び順は決定されていないため、ORDER BYの処理の前に行われるSELECTで上下の計算をすることができないのです。
OLAP関数は上下の計算ができない不便さを解消するためにできた関数です。SELECT句内（つまり、ORDER BYの手前のエクセルシート）で計算することができます。
ですから、OLAP関数のROW_NUMBER はサブクエリーを使わなくても利用できます。
しかし、SELECT句よりも先に実行されるWHERE句では使えませんので、OLAP関数の結果で抽出するには、サブクエリーが必要になります。
SQLは魔法ではないのですから、自分が「DBEngineを作るとしたら」「SQLの規格を作るとしたら」と考えれば、エクセルですらできるのにSQLが上下の計算が苦手な意味も分かると思います。
■ 覚えようとしたら覚えられない
わたしは、プログラム言語にしても、SQLにしても覚えようとはしていない。
覚えようとしたら覚えられないものです。
ところが、新人君のノートを見たら、ヘルプやリファレンスをまんま書き写したり、びっしり板書してたりってこともあります。
わたしなんて、ほとんどの関数やその引数を覚えていないのに（笑）。
学生の延長ですね。そんな字を書く練習より、理解するために脳味噌に汗をかかないとダメです。
とにかく覚えようとする人や、何でもよいから資格を取ろうとする人（勉強したことが実務に結びつかない人）は、苦行をやっているだけで努力の方向性が間違っています。資格を取ることが悪いとは言いませんけれど、もし、資格が取れたとしても、それはさらなる苦行の入り口に立っただけですよ。
わたしは、理解はしているけれど、記憶しているのはイメージだけです。
そして言語を習得するのに文法は後回しです。言語が何か、RDBMSのベンダが何かなんて、最後の最後まで気にしてないのです。それは、ものすごく遠回りに思えるでしょうし、一般的な教育とは真逆で、乱暴過ぎる勉強法かもしれません。
しかし、急がば回れです。
イメージがつくようになれば、例えば、「OLAP関数はSELECT句内で上下にも計算できる関数」と覚える（理解する）だけで、「必要なときにリファレンスを引けばよい」という状態になるし、「平均を取るには、多分、AVG関数ってのがあるのじゃないか？」ってあたりをつけて調べられます。
結論として、記憶力ではコンピュータには絶対に敵いませんから、最も重要な勉強法は「覚えずに理解することを心がける」ことじゃないでしょうか？
とはいうものの、勉強法なんて性格によって違うはず。さらに、わたしは相当の変わり者なので、万人に通用しないでしょうが、1人でもエクセルで試してくれる人が居たらうれしいです。
身に付いたら、ホントに変わるよ～。
■ 上流の人に（いい加減くどいな）
上流でコーディングすることがないのであれば（できたらした方がいいけどね）、手順をイメージできるようになるだけでとりあえずはOKです。「SQLで処理して欲しい」と言えるようになりますし、サブクエリーを使わねばならないポイントぐらいは指示できるし、DBサーバで処理する方を選べるようになります。
もちろん、下流にSQLが書ける人がいなければ指示を出す必要があるので、あなたも書ける必要があるのですけどね。できる人を呼んで来れるなら、あなたは手順をイメージできるだけでもよいです。
結果的に、テーブル設計も実にスマートになることでしょうし、テーブル設計より実装を先にした方が効率的というのも、体感的に分かるようになるでしょう。
どんな言語でも文法なんてどうでもよく、概念の方が重要なのです。それを理解せずに、すぐに文法をイメージするから低レベルの拒否反応が出るのだと思います。
ちなみに、APサーバで処理するということは、途中の結果のシートをメールで添付して他の人にやってもらい、次の処理依頼メール（SQL）を待つような処理になります。余程、特殊な処理でない限り、結果だけを返す方が効率的で、DBサーバの計算処理を少々減らしても、メールの送受信の回数や通信量が増えるなら、結果的にDBサーバの処理は増えてしまい逆効果です。
■ おまけ
他人の考えていることなど分かりようもないので、憶測で「（手順も考えず）文法から考えている」っていうのは、言いすぎかなとも思う。
わたしの文化では、手順が頭にないのに「書けるわけがない」ですから……。でも、みんな実行計画を見てないし、他の人の書いたサブクエリーがたくさん入ったSQLを解きほぐしても手順にならなくって、「何がしたいのかさっぱり分からない」って言ったら、「SQL分かんないんですか？」って言われたり（苦笑）。
「どう考えたらこのSQLになるの？」って思うことがよくある。
それで、もしかして（手順も考えず）文法にあてはめるだけで書こうといるのかな？ と思って書いてみました。憶測（おくそく）ですし、他の人がどう考えて書いているのか非常に興味がありますから、反論は大歓迎です。
しかし、もし、わたしの仮説「文法から考えている」が正しくて、本当に多くの人が手順を考えずにSQLを書いているのだとしたら、
- 手順（処理） → SQL
- SQL → 手順（処理） ※これはデバッグとチューニングに必要
の翻訳も、相当、苦労するのかも知れない。
これについて本でも書くとか、セミナーでもしたら儲かるかな（笑）。
一応、社長なので商売、商売！
もし、興味があるという方は info@g1sys.co.jp へメールをいただければ幸いです。
コメント
インドリ
非常に興味深い記事です。私も勉強なんて考えた事なかったので、共通する部分があります。
私も文法とか勉強しようとしたら駄目です。
技術者ごとにやり方が違うと思いますが、きっとみんな脳を酷使していると思います。
私だけ教えてもらうのは気が引けますので、自分の修得法も書きます。
私の場合はマトリックス状態です。
SQLは集合理論に基づいているので、粒子が飛び交っているイメージで覚えています。
それを一人の小人（自分の擬似人格）に担当させます。
私の頭の中には沢山の小人が居て、会話をすると各小人たちが自立的に働いて、現実のシミュレートをします。
つまり私は自分の頭の中に、マルチタスクシステムを実装しているわけです。
そのシミュレートをみて、
「このプロジェクトは○○で失敗します」とか
「エンドユーザーが○○の操作で困ります」とか
「○○でエラーを起こします」とか・・・
自分の頭の中の世界の光景で判断します。
しかしながら、データベース・ネットワーク・セキュリティ・システム管理者・プログラマ（各言語）・システムエンジニア・エンドユーザーなどの小人が居ますので、完全に私と話しが出来た人が現実のプロジェクトにはいません（笑）
どうやら分業化が進みすぎて、自分の得意分野以外全く知らない人が多いようです。
特に酷いのがいわゆる上流の人達で、まったく通じません。
何度も要求しようの段階で、このままではデスマーチになった上失敗するといっても私の忠告を聞いた人は居ません。
80％ぐらいの確率でシミュレート結果どおりになるのに、私が言った事すら覚えておりません。
インドリさん、ども。
インドリさんも小人なのね（笑）
私も小人に指示出しているイメージって書いてたけど、バカにされるかと思って消したんです。
多分、会話のペースでできる人は、小人かどうかは別として、右脳でイメージを作りながら、左脳で言語に変換してると思います。
しかし、そのペースでは書けないし、右脳のイメージは伝えられないので困っていたのです。
特にSQLは右脳の割合が大きいので、多くの人が苦手とするのじゃないかなと思う。ただ、エクセルを使うことによって、左脳を使ってもできるかなと……。
上流の人たちはネットワークとはほとんど口出して来ないし、言語的な間違いは実装が始まってから適当に直せる。
しかし、DBは破壊力満点なので何とか理解してほしいと思います。
インドリ
生島さんも小人！（笑）
やっぱり小人ですよね！
生島さんと同じく、私も右脳のイメージが伝えられなくて困った事が多々あります。
右脳って便利だけど、導出過程を聞かれると弱いんですよね・・・
情報量が多すぎて左脳で説明しきれません。
もう面倒でプロの勘といいたくなります。
それにしても、みんなは、命令型言語でも右脳を使わないのかな？
両方使えばいいのに・・・
ちょっと気になったのですが、
>上流の人たちはネットワークとはほとんど口出して来ないし、言語的な間違いは実装が始まってから適当に直せる。
この件についてなんですが、システム要件を勝手に決められて困った事ありませんか？
システムって、ほら、相互が複雑に絡み合っていますよね。
データベースだけ困る事はないと思うのですが・・・
SQLをテーマにした記事だからそう書いたと思うのですが、一応注意を書かないと誤解を受けると思います。
> この件についてなんですが、システム要件を勝手に決められて困った事ありませんか？
> システムって、ほら、相互が複雑に絡み合っていますよね。
もちろんあるのですけれど、そこまで言ったら贅沢かなと思うぐらいです。
小人が走っている人は、コーディングしなくても、その言語で書けなくても私としてはOKなんですけどね。
小人もいないし、コーディングもしないという人は、何を考えてグランドデザインを決めているのか、本当に不思議です。
saki1208
saki1208です。
みんな小人なんですかね?
わたしも小人ですね。
他人に説明する時もたまに「小人がね…」
って言っちゃいますね。
擬人化すると説明する時も少し楽なんで
すよね。(笑)
携帯からなのでこれで。
saki1208 さん、ども。
携帯でこの長ったらしいのを読んでいただいたのでしょうか。
恐縮です、ありがとうございます。
他にも小人で考える人もいるのが分かって安心しました。
気が付いた頃から、私の頭の中に小人はいたのですけれど、人には言ってなかった。昔はコプロとか、グラフィックアクセラレータという小人も活躍していたぐらいです（笑）
右脳で考えるタイプの人と、左脳で考えるタイプの人がいて、同じプログラムを作るという仕事をしていても、全く違うルーチンで答えを出しているということは、私としては大発見です。
で、私など、絵とか音楽とかの才能は悲しいほどないので、出力は右脳では出来てない。右脳で考えるか、左脳で考えるかも、おそらく同じで、大人になってから変わるものでもないかもしれません。
コーディングしている人は、少なくとも出力は左脳で出来ているということですが、オブジェクト指向は、UMLのように右脳で考えることをサポートするものがあるから、左脳タイプの人たちにも理解しやすく、そちらの方が簡単という結論になるのかな？
SQLは左脳だけではうまくいかず、右脳をサポートするものがなかったから難しかったんじゃないかと思います。
エクセルでサポートできたらいいな。
小人が出てくるタイプの人間が、文法からのロジカルシンキングする左脳タイプの人たちの思考ルーチンを想像しての話ですから、ものすごく外しているかもしれませんけれど……。
エントリーポート
生島さん、はじめまして。
いつも楽しく拝見させていただいてます。
私の場合は、クエリー1個書く毎に
ベン図の丸が頭の中で生まれます。
Excelシートの発想は意外でした。
みんなそれぞれですね。
ちなみに、重箱の済みつつきかもしれませんが、
SQLの評価順は、
1. from
2. where
3. group
4. having
5. select
6. union
7. order
8. limit
ですよね。
エントリーポートさん、はじめまして。
UNION 忘れてました。
HAVING は……、GROUP時点で集計して算出処理してますね。
失礼しました。
これね
HAVING SUM(CASE WHEN xxx THNE COL1 ELSE 0) > 1000
みたいな説明しようとしてました。
プロならエクセルのIF関数は抵抗ないでしょ？
エクセルでやるとき、「IF関数をCASE式に置き換えたら良いんですよ～」って続きを考えながら書いてたら、SELECT の後の方が説明しやすくて間違えた（笑）
その場で考えてて、記憶で書いてない証拠で笑って許してください。
私もベン図とかも出てくるのですけれど、サブクエリーがたくさん出てくるような物になると、ベン図を小人が操作しているイメージになってきます。
そのイメージをなかなか他人に伝えられなくって本当に困っていました。
エクセルで分かってくれる人が増えたらよいのですが……。
インドリ
多くの人が小人を住まわせているようですね（笑）
そういえば、この小人何時から住んでいるのでしょうか？
私自身にも分かりません。
デスマーチをこなしているうちに気付いたら住んでいたような・・・
初め私はペン図を脳内で書いていました。
やっぱり初めはペン図がいいですね。
慣れるといつの間にか情報が粒子になって、マトリックスの構成物の一つとなる。
そして気付いたら小人が居る。どうしてそうなったのか私自身も分かりません。
なので、新人に学習法を教えられません。
そんな私に比べて、EXCELでの方法を考え付いた生島さんは凄いです。
技術継承はこの業界の課題ですね。
m2
我々マルチタスク思考ができる人間には、ＳＱＬもアジャイルも、上流工程も、結果的にうまくできるんです。
でも、世の中の多数派はシングルタスクでしか動けないのです。
思考しながら行動するなんてできないのです。
だから、いくら結果がうまくいかなくてもウォーターフォールはすたれないのです。大多数の人にとっては、アジャイル的思考が向いていないのですから。
そういう人にとっては、文法があって、システムがあるのです。
そういう人の方が多いのですから、規模を追求した場合、これらの多くの人が適応できない方式ではだめなのです。
私もＵＩがc#.netでビジネスロジックをPL/SQLというフレームワークを作って開発したことがありますが、フレームワークの開発を入れても従来の半分程度の工数だったみたいですから、このやり方は効率はいいと思います。
実際に使った人は良さがわかるのですけどね。
ＵＩもビジネスロジックもどちらもウォーターフォールで開発できるから、こういう多数派の人が無駄なく使えます。
PL/SQLなら、手続き型言語なので、ＳＱＬは単純なものだけわかれば書けるのです。特別に時間がかかっているＳＱＬだけ、最後にチューニングすればいいじゃないですか。
我々はフレームワーク・データベース・ハードウェアの設計だけやっていればいいかと。
皆に技術力をつけさせる方法より、技術力のある人を有効に使う仕組みを考えるほうが良いかと。
どうやったら小人が住み着くかというと、生まれ持ったものかな。
私は絵描きとかには絶対になれないから同じことだと思う。
小人が住んでる人はあまり会いませんけどね。
何人かは、似た思考ルーチンで答えを出してるなと感じたことはありますが、絶対数は少ないと思います。
逆に、文法の訓練で書ける人って本当にすごい。
その
それで、小人がいる人は本当に新人教育ができませんね。
私も、「アルゴリズムから教えないといけない」ということを知らなかったし、どうやって教えてよいのやら本当に悩みます。
教えてあげたいけど伝えられないです。
小人が住んでる人は、EXCELで訓練ってだけで「その手もあるよね」ってほとんど説明が要らないぐらい理解してもらえるのでしょうけれど、住んでない人は「何をバカなこと」って言われてしまう気がする。
伝えたいのに伝わらないというのは本当にイライラするものです。
ただ、「EXCELで手作業で可能」なことは必ずSQLで表現できます。
ということは、ほとんどのことはSQLでできる証拠なんです。
確かに言語仕様はダサいのですけど、ちょっとやってみたら慣れるのに。
m2さん、始めまして。
> 私もＵＩがc#.netでビジネスロジックをPL/SQLというフレームワークを
> 作って開発したことがありますが、フレームワークの開発を入れても従来の
> 半分程度の工数だったみたいですから、このやり方は効率はいいと思います。
・・・
> PL/SQLなら、手続き型言語なので、ＳＱＬは単純なものだけわかれば書ける
> のです。特別に時間がかかっているＳＱＬだけ、最後にチューニングすれば
> いいじゃないですか。
> 我々はフレームワーク・データベース・ハードウェアの設計だけやっていれば
> いいかと。
おっしゃるとおりなのですけどね、先ず分けることなんですがDBサーバで処理することすら既得権を奪われる人の抵抗で「APサーバで！」ってなってしまうし、上流でDBが分かってない人がテーブル設計などなどするからとんでもないことになっちゃいますね。
それを、バカして起業しちゃったから後には引けないので、微力ながら「変えたい」って思っているわけです。
私はバカなドンキホーテなのは認識しています。
「できる人」は見てて「おもろい奴やな～」と笑えるでしょう。
笑える人は、何割ぐらいなのでしょうか？
「むかつく！」と思う人は……、何割ぐらいなのでしょうか？
saki1208
saki1208です。
今日も携帯からですが…
# 見る分にはiPhoneなので困りません。
うちは、作るシステムのほとんど全てが
未だに二層です。
作るのもテストするのもつきっきりで、
どっぷりはまらないと作業できません。
そうやって作ったシステムに頻繁に改修
が入るので改修後のテストが…
SQLでのデータ処理部分とUI関連の部分
とを切り離すだけでも随分楽になると思
うのですがねぇ。
# 一部ではその意見を取り入れて貰って
# 開発者には好評をえています。
なかなか、過去と違う手法を受け入れて
貰えません。
エントリーポート
エントリーポートです。
>確かに言語仕様はダサいのですけど、ちょっとやってみたら慣れるのに。
え、SQLがダサいですか？
知る限りポインタを隠しきった最高の言語だと思いますけど。
（うーん、3値論理の話は無視しておきます）
まあ、主観は置いといて
ベン図の話をしましたが、
私の頭の中にも小人さんがベン図を書いて
さらにHDDのイメージに結び付けてくれます。
（時々、ベン図の丸でボール遊びしてくれるので
わけわからなくなり困りますが）
人に教えるときには、HDDに入っていることを
忘れないでと伝えることにしています。
でないと、とんでもないSQLが出てくるので。
エントリーポートさん、ども。
SEQUEL（Structured English Query Language）とは違うと言っても引きずっているのは明らかで、英語を意識したままなのでしょうね。
個人的には、語順を処理順にしてないから、特に日本人はSQLを魔法と思ってしまうのではないかと……。
SQLから直接的に処理に繋がらないじゃないですか。
エントリーポート
生島さん、ども。
>SQLから直接的に処理に繋がらないじゃないですか。
確かに、SELECTから始まってることに
疑問を感じてませんでした。
でも、SELECT作るときは、Fromから
作ってるなー。
（入力補完の都合上）
確かに、SELECTを処理順にしたら
分かりやすいかもしれませんね。
SQL文は「動詞から始まる＝命令文の英語」のつもり（笑）って思っている人、どれぐらいいるのでしょうね（笑）
私は「それを目指したんだろうな～、でもそれは無茶でしょ」っておもってます。
日本人には、とても、英語（命令文）には見えてないのじゃないかな。
でも英語を母国語にする人も気持ち悪いと言ってるような……。
oumi
こんにちは。
小人人口？意外と多いのかな（笑）
小人がうごめくのもすごいですね～、面白い。
私は小人ではないですが、頭の中で絵が動きまくります。昔あったトロンのような感じです。
ＤＢを考える時も、アプリケーションを考える時も、システム全体のときでも、その時々のスケールに合わせて絵が蠢く感じです。
ネットワークのことを考えるときは、なんていうか、水道管の中を０と１が飛んでいくような感じだったりします。
面白いですねこれ。他にもまだまだいろいろな人がいそうです。ぜひ聞いてみたいですね。
勉強法の話ですが、私の方法は、特にこれというのは無いのですが、
SQLに限らず、まず最初に言語の目的を知るということでしょうか。
そのあとは特に勉強らしき事はせずに、リファレンスの見方を覚える。
くらいです。言語の目的が判ってしまえば、どの言語もそんなに大差はないと思っています。文法などは若干知る必要はあるかもしれませんが。
多分、最初にアセンブラから入ったせいかもしれません。
勉強法についてもいろいろな人の話を聞いてみたいですねー。
実に面白いです。
oumiさん、ども。
オブジェクト指向のときは、モノが浮かんでくるのですけれど、SQLも業務フローも小人がワーっと動き回るイメージですね。
今まで、「説明して」と言われても、小人のイメージは伝えられなかったのです。
言語の目的（概念）は重要ですね。
私はアセンブラは実務でやってないのですけれど概念は分かります。
話はそれますけれど、分かってない人は、直感的に
int の 1 と float 1 と String の "1" ・・・
を同じものと見ている人がいます。
他人の考えることは分からないので、予想ですけれど、つまり、直感的に「違うもの」と思っている人と、「同じなのにエラーが出る（エラーが出るから直す」と思っている人が居るように思います。
両者は行動はあまり差がないので普段は見分けは付きにくいですけれど、大きな差があると思っています。
私も理想論ばかり言ってるのではなく、「あぁ、こいつ分かってないわ～」と思っても、まず第一歩として、実務で影響が大きなSQLを何とかしたいと思って目をつぶるのです。
私はプログラムの教育を受けたことがないので、これも憶測ですけど、とにかく、プログラムの教育をするのに、公式にあてはめる様な教え方で、促成栽培しようとするのがいけないと思う。
それで、公式にあてはめてSQLを教えるのは難しいしから、SQLができない人が多いのだと思ったり。
小人の動作をまとめたらExcelにたどり着いたのですけれど、公式にあてはめるのに近いような気がするので、公式をあてにする人たちにもメリットがあるのじゃないかと思ってます（自画自賛）
oumi
こんにちは。
もしかすると、SQL文を覚える人が少ないのは（できない人が多いのは）RDBMSがとかだけではなくて。
・言語系：言語学的思考があればあるほど理解できる。
・SQL文：実は言語学的思考より、数学的思考が必要。もっというと想像力かな・・
なので、苦手な人が多いのかもしれませんね。
ExcelでSQLを説明する、いいですね。Excelからの話ですと応用ききますね。
VBA(Excelのマクロ)：ストプロって感じですし、シートのプロパティがSYS_だとか言えそうですし。
何よりもExcelだとはじめての人でも抵抗感が無いのがいいですね。
するきになれば、ロックの仕組みやACIDの説明も見せながらできるなぁ。
「Excelで始めるDBの基礎」
Excelから始めてSQL文の完全理解まで！
なんて本書いても良さそうですね。
oumiさん、ども。
SQLができる人が見れば、このぐらいの文章で最後までほぼ想像がつくということですね。
しかし、SQLが苦手な人にどのぐらい伝わったのだろうか？
今、イロイロと続きを考えているのですけれど、全くの初心者でも、Excelの素養があれば1日のセミナーでサブクエリーてんこ盛り（になるのはテーブル構造に問題があるはずですが）のSQLまで脳内コーディングできるようになるような気はしています。
社員にまた自分基準で考えてると怒られそうですが（笑）
構文（文法）の説明の前にインデックスを使った結合や、インデックスを使わないネスティッドループを手作業で体験してもらう。私にとってはかなりイケてるカリキュラムに思えます。
「手作業でやってください」って言ったら、プライド高い人たちの抵抗がどれぐらいかが気になるのですけどね。