生島 勘富SQL講座

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

昨日の例では、売上ヘッダ・売上明細がメインループになっていましたが、商品マスタがメインループになる場合について考えてみましょう。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

SQLは英語で基本設計と一致することを目指してますから基本設計をよく読めば分かる。残念ながら日本語の語順では最後に書いてあることが多いけれど。「ｘｘｘｘｘｘの条件と一致する商品の一覧を出力する」というとき、商品の一覧を出力するのだからメインループは商品マスタ。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

要は何が欲しいか。欲しいものがメインループ。当たり前すぎるな。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

例えば「期間中に売上があった商品マスタを出力する」であれば、SELECT * FROM 商品マスタ （期間中に売上があったとなる WHERE 条件）となります。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

細かい方から考えるのではなく、文章の大意から考えるのがSQLの考え方な訳です。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

では、脳味噌を手続き型モードに一旦戻して、「あれ？俺は売上の方をメインループにしようとしたぞ！」って人もいるでしょう。正しいです。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

つまり、「売上の方をメインループ」にした人は、まず、対象となる「期間中に売上があった商品の主キー」の一覧を作ってそれにヒットする商品を出せばよいと考えた訳です。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

これをSQLで表現すると、「期間中に売上があった商品CD」の一覧 http://codepad.org/EizkXizr を、欲しいメインループ http://codepad.org/8UiZ7of5 のキーの一覧と置換すればいい。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

このときに利用できるインデックスは、インデックスが存在すれば【売上ヘッダ.売上日】と、【商品マスタ.商品CD】になります。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

内部的に、一覧の件数回 http://codepad.org/8UiZ7of5 が実行されることになるので、選択された一覧の件数が少ないときは高速になる。多いと遅い。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

手続き型モードの脳味噌で、「イヤ、俺は商品マスタの方をメインループにしようとしたぞ！」って人もいるでしょう。正しいです。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

商品マスタをメインループとするということは、ループしながら条件に合うか確認する（対象外のとき読み飛ばす）ということになるでしょう。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

これをSQLで表現すると、欲しいメインループ http://codepad.org/8OZpq6gL の(売上があった条件)を http://codepad.org/KbMbdTvl で置き換えればよい。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

このときに利用できるインデックスは、インデックスが存在すれば【売上ヘッダ.売上日】と、【売上明細.商品CD】になります。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

どちらのループを書いても結果は同じになりますが、手続き型言語で書いても、どちらの方針になるかはSE/PGが考えるところになるでしょう。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

これが、INとEXISTSの違いです。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

結果が等価になるから、INなら分かるという人が多い。これは、INの後ろに来るのは単純なサブクエリ（単独でも実行可能）EXISTSの後に来るのは相関サブクエリ（単独では動かない）ためだろうけれど全く同じじゃない。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

IN と EXISTS は、EXISTS の方が速いとか迷信で、どっちのインデックスを使いたいか。で考えればいい。インデックスの概念がなければどちらが正しいかなんて言えない。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

FROM句、WHERE句を徹底的に鍛えたら、そこから先はエクセルシートと同じです。サーバのメモリー上にエクセルシートが展開されたイメージを持てばいい。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

サーバ上に展開されたエクセルシートをイメージして、集計して集計行のみを出力したいならGROUP BY。さらに、集計結果で絞り込みたいなら HAVING。明細と集計を同時に出力したいならOLAP関数。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

SELECT句は同じ行なら、エクセルと同様に関数、数式が利用可能。どうしても上下の比較などがしたいときなどはOLAP関数を検討する。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

とにかく、FROM句、WHERE句までできたら、後はエクセルと同じと考えれる。つまり、エクセルのできる事務職の人なら大抵できるわけです。逆にできない人は、FROM句、WHERE句までを文法解説の入門書で文法に合わせてなんとかこなそうとしている。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

ループから考えてそれをSQLに置き換える。そういう訓練をしていれば、SQLが書き終わったら、ほぼ、チューニング済みと言えるSQLをいきなり書くことができます。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

文法に合わせようとするから身につかないし、何が便利になったか分からない。しかし、ループのイメージを持った上で、面倒なループを書かなくてもDBエンジンが処理してくれると考えれば「なんて便利なんだ」と分かる。

SQLの苦手を克服する本(技術評論社)/生島 勘富 @Sikushima

どちらのインデックスを使うか、どんなループを回したいかですよ。 QT @NewGyu: ん？ EXISTSの方が1件ヒットで探索打ちきるので有利なのは事実なような。RDBMDの実装によりますが。