SQLさん、ごめんなさい
わたしはプログラマ歴は長いんですけど、SQL歴は短いです。
別に避けていたわけではなく、データベース（以降DBと略）を扱うプロジェクトに放り込まれたことがほとんどありませんでした。DBを扱うシステムに関わった時も、そこにはDBのマイスターと呼ばれる方々がいらっしゃって、全部をお膳立てしてくださっていたので、本を読んで文法を覚えただけの状態でもなんとかなっちゃったものだから、それ以上のことを追求する気がおきなかったんですね。
一度、SQL Server 2000のインストール、テーブル設計、SQLおよびJavaのコーディングをすべて1人きりでやる機会があったんですが、その時は速度性能をまったく要求されなかったので（←動く様子がわかる程度のものを短期間で作ってくれ、というオーダーだった）、これまた本を読んだだけの知識でなんとか乗り切れてしまいました。
とにかくわたしはSQLにまったく興味がありませんでした。好き嫌いの問題ではなく、関心がゼロ、という状態です。
SQLはDBの専門家が扱うもの、というイメージがあったので、そこは管轄外という思い込みもありました。わたしがDBが関係するシステムに携わるときにはいつもチームに専門家がいたので、そういう方々がいなくてC++やJavaを書いてるプログラマがDBの面倒までみるという状況はめったにないものだと思っていたんですよ。
本当に「常識」ってコワい……。
そんな状態でIT業界を渡ってきちゃったわたしなんですが、今の会社に入った途端にSQLが必要な仕事を任せられてしまいました。
しかも、そういったものが業務の中心になっているらしい。
これは今のSQLのスキルレベルでは乗り切れないような気がする、と思ってとりあえずどんな感じのものが動いているのかを確認するために、わたしの権限で見られる範囲のDBに入っていたストアドプロシージャとビューをすべて読みました。多分100本以上ありました。
実をいうと、実際に運用されているSQLを読んだのは初めての経験でした（本当に縁が薄かったんだなあ）。
大量のSQLを読んだ後の率直な感想は、「SQLってこんなに自由な言語だったのか！」でした。
なぜだかSQLをずいぶんと窮屈な言語だと思っていたんですが、それはわたしの認識不足でした。SQLは創意工夫をいくらでも詰め込めむことができる言語だったんですよ。「そうか、SQLもプログラミング言語だったんだ」とか大ボケなことを思ったりして（苦笑）。
で、最初は流し読みだったんですけど、この人はプログラマとしてちゃんとしている、と思った人の署名が入ったストアドプロシージャをじっくり読み直してみることにしました。すると、たまに不自然に遠回りしている感じがするコードに出合うんです。
試しに、同じ結果を出すんならわたしはこう書く、というサンプルを書いてみて、速度を計ってみると、元のコードの方が全然はやかったりするわけです。へたすると10倍くらい差がでます。愕然です。
じゃあこう組んだらどうなるの？ といろいろといじくりまわして、元のコードよりも早いタイムをたたき出した時は感動でした。「エウレカ～！」と叫びたかったくらいです（さすがにやりませんよ！）。
そんなタイムトライアルを繰り返している時に、このSQLをC++にコンバートするとしたらどう書くだろう、と思いついてちょっと頭の中で書いてみたんですけど、これがものすごく長くなっちゃったわけです。
こんなに長い処理がこんなにすっきりしたコードで表現されてるのかっ！ おもしろいっ！ めっちゃおもしろいじゃないか、SQL！！
そんなわけで40にしてSQLのおもしろさに目覚めました（←いろいろと遅すぎるからっ）。
おもわず「SQLさん、ごめんなさい」（←なぜかさん付け）と思いましたね。
「きみがこんなにステキに楽しい言語だなんて気づきもせずに、遠くから眺めてただけだったなんて、本当に悪かったよ～」（←だいぶイタイ人だと思われそうだ）。
ちなみに、その後、ネットで調べてみたらチューンナップの情報があちこちに大量に転がっていて、むきになってトライアルを繰り返す必要はなかったことが判明しました（←先にググろうよ、自分）。まあ、楽しかったからいいんですけどね。
以前のわたしのように、SQLが縁遠くって遠巻きにながめている方には、SQLで遊ぶことをおすすめしたいです。
いい思考トレーニングになると思いますよ。SQLはデータとデータをつなげるという情報処理の基本機能を、ダイレクトにみせてくれる言語ですから。
で、何が言いたかったのかというと、生島さんとこの記事とコメント欄のO/Rマッパーを積極利用すべきか否かというおはなしを読ませていただいて、「SQLを書くのはめっちゃ楽しいから、O/Rマッパーには譲りたくないなあ」と思った、ということなんでした（いろいろとためになることがたくさん書いてあったはずなのに、こんなしょぼい感想しか出てこなかった）。
コメント
士郎
こんばんわ。
SQLに業務で深く携われるかどうかは会社によって違いますし、運なども
絡んでくると思ってます。本人がいくらやりたいと言っても会社に
所属している以上業務命令は無視できませんからね・・。
私も正直SQLとはあまり深い関係にはなれませんでした。しかし、ちょうど
１年ほど前かなオフショア引き継いで開発してたんですが、副問い合わせや
外部結合がいくつも重なった今まで経験したことが無いちょっと長いSQLに
最初のころはてこずりました。
ちょうどその辺りに生島さんのここのコラムを見て自分のレベルの低さに
かなりショックを受けました（笑）。
それからは、SQLやDBを中心にいろいろな方から勉強方法や良書を教えて
いただき勉強してきました。
不思議なものでいろいろな書籍読んでいると本当に奥深いなあとよく思います。
集合型言語ですから数学の勉強もし直したりといろいろやっていますが、
まだまだ未熟ですね。
ひでみさん、お互いSQLにはまっているようですのでがんばって使い
こなせるようになりましょう！
インドリ
こんばんは。
SQLを扱うのは楽しいですよね♪
saki1208
ひでみさん、こんばんは。
saki1208です。
私はPCでの開発作業に関わるようになってから殆どの期間SQLとともに
過ごしてきました。はじめは単純なSELECT文しか書けませんでしたけど
ね。でも、やればやるほど奥が深いことを思い知らされます。
初めてストアドを使用したときはあまりのパフォーマンス差にカルチャ
ーショックを受けました。
当時、Windowsは3.1でしたしNTはAdvancedServerの時代でした。
OracleもWindows版が出たばかり?で周りに質問できる技術者もおらず、
大変苦労したのを覚えています。
# SQLの実行中にWindows3.1がフリーズしてリセットするとOracleが
# サーバごとお亡くなりになるため、リセットするたびにプロジェクト
# 室に「リセットするぞっ!!」て雄叫びが...
ひでみさん、こんばんは。
そうですね、Javaも.Netもおもしろいけれど、SQLは楽しいですよ。
実行計画が読めるようになると、一気にSQLが楽しくなるのですけどね～。
偉そうなことをいうと30年前に生まれていたら「俺がSQLを作っていた」「語順は処理順にしてたぞ！」と言いたいところです。
もっとも、表計算ソフトに触れてSQLらしきモノを考えたので、表計算ソフトがなかった30年前に生まれていても、まず、思いついてないけれど……嫉妬するな～。
やの
成長できる仕事に出会える運・・・だよなぁ・・・
自助努力にも限界を感じます。
・・・人
－－－－－－－－－－－－－－－－－－－－－－
・・・人
－－－－－－
－－－－／
－－－－－－／
壁がなければ成長できませんって。
・・弱音を吐くな？そうなんですけどね。
ひでみ
こんばんわです。アリージョひでみです（爆）。
士郎さん。
> SQLに業務で深く携われるかどうかは会社によって違いますし、運なども
> 絡んでくると思ってます。本人がいくらやりたいと言っても会社に
> 所属している以上業務命令は無視できませんからね・・。
プログラミングに興味を持って最初に手を出すとしたら、Web言語とかJavaを選ぶのが普通で、仕事がからんでないのにSQLに手を出す人はかなり少数派な気がしますね。
> ちょうどその辺りに生島さんのここのコラムを見て自分のレベルの低さに
> かなりショックを受けました（笑）。
その気持ちよくわかります（苦笑）。
いろいろとわかってきたつもりだったのに、まだまだ先があるんかい！ みたいな。
せっかくSQLのおもしろさに気づけたんだから、もっとしっかり使いこなせるようになりたいと思っています。
インドリさん。
> SQLを扱うのは楽しいですよね♪
SQLも楽しいし、VBも楽しいし、C++も楽しいですよ！
saki1208さん。
> OracleもWindows版が出たばかり?で周りに質問できる技術者もおらず、
> 大変苦労したのを覚えています。
昔、Oracleに苦労したメンバーが「“神託”なんてえらそうな名前つけるな！」と、妙なキレ方をしていたことを鮮明に覚えています（笑）。当時は資料が少なくて、相当、苦労していたんだろうなあ、と今になってみるとわかるんですけど、当時は「商品名にケチつけなくても……」と思ってました（わかってやれなくて悪かったなあ）。
生島勘富さん。
> 実行計画が読めるようになると、一気にSQLが楽しくなるのですけどね～。
手続き型言語（FORTRAN、C/C++）で育った人にとっては、処理の流れが明確に見えないところがSQLの最初の関門のような気がします。だとすると、実行計画から入る、というのが実は一番、効率的なSQLの学習方法なのかもしれません（私はそれの逆ルートをたどってますけど）。
やのさん。
> 自助努力にも限界を感じます。
> 壁がなければ成長できませんって。
プログラマという仕事に関しては、壁がない、と感じたことがありません。
なんだか常に壁壁壁という感じです。
同じように自助努力にも限界はないと思いますが、正直、自助努力に疲れることはあります。
あまりに他力本願ではまずいですけど、他力（他者からの刺激？）がないという状況は厳しいですものね。
放浪者
> 手続き型言語（FORTRAN、C/C++）で育った人にとっては、
> 処理の流れが明確に見えないところがSQLの最初の関門のような気がします。
同感です。
最近SQLの勉強を始めたのですが、手続き型言語の概念があまり役に立たないので、壁を感じます。
昔verilogっていう言語を勉強した時も、概念の違いに苦労しました。
その時の教訓は、壁を乗り越えるには試行錯誤あるのみってことでしょうか。
小学生のころやらされた数学ドリルって、そういうことなんだろうなーと今更ながら思います。
ヴァン
こんにちは。
SQL歴はプログラム歴の1/10です。
元々いた業界が違うのでこんなものです。
今のところ、SQLに感動してます。
>SQLはデータとデータをつなげるという情報処理の基本機能を、ダイレクトにみせてくれる言語ですから。
まさにこのことですね。
だたのデータの集合体がSQLで繋がることで意味にあるデータになる。
凄いことだと思います。
ひでみ
こんばんわです。ひでみです。
放浪者さん。
> その時の教訓は、壁を乗り越えるには試行錯誤あるのみってことでしょうか。
そうですね。単純ですけど、試す→考える→試す→考える、を繰り返すしかないのかなあ、と思います。
試し方を工夫しないと、ムダにループしてるだけ、になるおそれがありますけど。
ヴァンさん。
> だたのデータの集合体がSQLで繋がることで意味にあるデータになる。
そうなんです。それが本当に楽しいんです。
「データ」と「インテリジェンス」の違いとでも言うんでしょうか。
データは蓄積するだけでは、ただのリソースの食いつぶしですからね。
それにしても、目的もはっきりしないままに溜め込まれてるだけのデータって、世の中にどれだけあるんだろう……。
ひでみさん、こんばんは。
余所様のところで失態を晒してしまい反省している最中なので、癒しを求めてマッタリしに来ました（笑）
実行計画が読めて良かったことがあります。
過去のプロジェクトで、リーダーが『なんでこんなに照会が遅いんだー！』と騒いでいて、当時最年少だった私に疑いの目が及んだことがありました。
『ここの実行コストは本番データのコストベースで実行コストが12しかないんですよ！』
と言えたことで、一瞬にして解決しました（その前にサーバーログを見て欲しかった）。
あと、他人の書いたJOINが７～８回出てくる”力作”のSQLを修正しなきゃならないケースに何度も遭遇したのですが（書いた当人はお役御免でもう居ない）、ちょっとの修正で解決したことは皆無なんですよね。大抵はゼロから作り直すことで行数も少なくなり、速度も大化けしてました。それだけに、SQLも基本が重要だなぁと思う次第です。
すみません、肯定でも否定でもない単なる雑談でした（笑）
追伸：
SQLのチューニングにはコストベースとルールベースとがあります。ご興味があればググって（笑）頂ければと思います。
未だに”金字塔”というワードが頭から離れてないです（笑）
いや、最大限の親しみを込めての微笑です（←神経質になってる）。
ひでみ
こんばんわです。ひでみです。
ちょりぽんさん。
> 癒しを求めてマッタリしに来ました（笑）
私もちょっとマッタリしたくてこのネタを選んだんですが（苦笑）。
> 大抵はゼロから作り直すことで行数も少なくなり、速度も大化けしてました。
> それだけに、SQLも基本が重要だなぁと思う次第です。
SQLはちょっとしたことで速度がものすごく変わるので、それがおもしろいですね。
「このマシンを一番、速く走らせてみせる！」と言う最速ドライバーを目指すのも楽しいですが、「ドライバーにもっとも安全で快適なマシン（＝システム）を提供してみせる！」と言える凄腕メカニックになれたらかっこいいよなあ、と思います。
ちょびちょび
ちょびちょびです。また寄らせてもらいました。
穏やかな晴れた週末の午後に、なんと相応しいマッタリした話題。そうですか。ひでみさんはＳＱＬにあまり縁が無かったんですか。ちょびちょびはＷｅｂチームがお客様のお問い合わせに素早く対応できるよう、データを加工して用意しておく系の作業が多いです。
そんなとき、まとめ役の方が手際よく動いてくれればインターフェースだけきっちり決めて、物理的にも作業場所を分けてくれたりすると快適に過ごせるのですが、同じフロアで混然と作業することになると軋轢が生まれる。
Ｗｅｂ：「え～。照会されるかどうか分かんないデータを、加工しておくの？ 無駄じゃん」「つーか、コボラーのおばさんウザいし」
ちょび：（ストアド、ＣＯＢＯＬで作ってないし）（つーか、検索条件が入力されてから集計したらどれだけ時間が掛かるか計算してから言ってんのかよ！）
みたいな感じでしょうか。Ｗｅｂチームのチャラいリーダー、デスノート行きです。しかし、作業が一段落してお客様から一言「おお。早いね～。キレイだね～」とお言葉を頂いたとき、チャラ男くんが、なんとも複雑な表情をしたのを見て、実行順序のプライオリティーを少し下げておきました。（削除はしない）
ひでみ
こんばんわです。ひでみです。
ちょびちょびさん。再びのご来場（？）まことにありがとうございます。
> 検索条件が入力されてから集計したらどれだけ時間が掛かるか計算してから言ってんのかよ！
実は私は今の会社に入ってから、そういうことを考えるようになりました（←遅すぎるからっ！）。
というか、それまで誰かが事前にデータを準備して置いておいてくれたので、それは最初っからそういうことになっているものだと思っていました。DBの担当者さんにいろいろと甘えてたんだなあ、と今になって思います。
もしかしたら私も誰かのデスノートに書かれているのかもっ（←有り得る）。
> 実行順序のプライオリティーを少し下げておきました。
なるほど、デスノートにはプライオリティの定義も必要なんですね。参考になります（笑）。
あきら
こんにちは。
SQLを書くことがめっちゃ楽しいという分かって良かったですね。
過去、私にも同じような体験がありました。
確かにSQLではすっきりしたコードで書くことができますね。
私の場合は当時、PHPでSQL文を作成し、それをDBサーバ(ORACLEやSQL Server)に送ってSQLを実行、結果をPHPで受け取る、といった事をしていました。
その頃はプログラミング言語でSQL文を作成し、DBサーバに投げて結果をもらう、というのが一般的でした。
その時、私は常々、思っていました。「プログラミング言語の中で"文字列"でSQL文を組み立ててDBサーバーに投げるのは何だかなぁ。実行時じゃないとSQL文のエラーが判定できないのは不便だなぁ」と思っていました。
今、私はC#を勉強しています。C#にはLinqがありますね。
LinqにはLinq to ObjectやLinq to SQLがあります。
C#という言語の中でSQLっぽい文が書けるんです！
今、私はLinqを使ってSQLっぽい事を書くことがめっちゃ楽しいです！
匿名
>（以降DBと略）
どういうこと？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？