「スッキリわかるSQL入門」読書会レポート vol.6

読書会

株式会社リゾーム 技術部 システム開発 第1グループの小田です。 今回は「スッキリわかるSQL入門」読書会の第6回のレポートです。

過去のレポートはこちらからご覧いただけます。

「スッキリわかるSQL入門」読書会レポート vol.1 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.2 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 3 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 4 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.5 - リゾームのテックブログ

読書会の題材

前回に引き続き「スッキリわかるSQL入門」を題材としています。

6回目レポート

6回目は第7章「副問い合わせ」のレポートになります。

今回の参加者は6名でした。

参加者の感想・意見まとめ

7.1 検索結果に基づいて表を操作する

  • 「副問い合わせ」より「サブクエリ」という呼称の方がよく使う。
  • 副問い合わせのSELECT文自体は単純な構造だけど、入れ子にすることで複雑な集計をさせられる。
    • 括弧とインデントでサブクエリのブロックを意識することと、サブクエリの結果が値に化けるというイメージは大事。
    • クエリが複雑になるほど、可読性を意識して書くのが大切になってくる。
  • 安直に副問い合わせを書いてしまうと可読性が下がってしまったり、パフォーマンスに影響があるかもしれないのでイマイチだけど、業務ではよく使う。
    • 場合によってはJOINの方がパフォーマンスが良いケースもある。
    • 副問い合わせとJOINどちらがパフォーマンスが良いかについては、RDBMSの種類によって速度に大きな違いが出るのでどちらが良いか一概には言えないらしい。SQLのパフォーマンスチューニングは奥が深い...。
  • （コラムについて）データ構造の基本をスカラー、ベクター、マトリックスと呼ぶのは初めて知った。
    • 3パターンに分けて勉強するのは分かりやすくて良いと思った。

7.2 単一の値の代わりに副問い合わせを用いる

  • 1つの値になるから比較演算子を用いて比較できる。
  • 集計関数と合わせると効果的に使えそう。
  • 副問い合わせの内容が長くなりがちで、かつそれがSELECT句の途中に入るので可読性の工夫が要ると思う。
  • INSERT時、IDを採番する際にレコードのIDに+1した値をセットする副問い合わせを書いたりする。

7.3 複数の値の代わりに副問い合わせを用いる

  • 複数の値のため比較にはANYやALL、INを用いる必要がある。
  • テーブルに直接値が入っている場合は使えそう。
  • 「NOT INまたは<>ALLで判定する副問合せの結果にNULLが含まれると全体の結果もNULLとなる」
    • NULLに注意が必要！NOT INの動作は罠だなぁ。
    • 普段NOT INを使うことはあまり無いが、いざという時嵌りそうなので覚えておきたい。
    • NULLを除外する方法：
      • サブクエリのWHERE句でIS NOT NULLを指定する。
      • COALESCEでNULLを別の値に置き換える。
  • ひねりの効いた使い方というか、演算子との組み合わせ方やNULLへの配慮など考えないといけないが使いこなせると便利だと思う。

7.4 表の代わりに副問い合わせを用いる

  • 製品の検証作業時に分析結果の確認などでよく使うパターン。
  • FROM句やINSERT文では本当によく使う。特に複数データ登録するときにINSERT～SELECT～は超便利。
    • INSERT-SELECTは本にも書かれているけど、厳密には副問い合わせではない。INSERTがサポートしている特殊な構文。複数のテストデータを用意するときに使った記憶がある。
    • INSERT文の特殊用法は読みづらいけど、1塊ごとに考えていくのを意識していきたい。
    • FROM句で長い副問い合わせを書くと、書いた本人でも読みにくいなと思うためあまり書きたくない。最近WITH句を覚えたので、できればそっちを使ったりしていきたい。
  • 外側のSQL文の列を使う相関副問い合わせは使う機会はあまりなさそう。
    • 相関副問い合わせなんてものがあるんだな…。同じような書き方だけど内部的な動きやコストが違うのは罠だな。複雑な処理を書いていると、気づかないうちに相関になっていた、なんてことがあったりするのかな。
    • 大体はテーブルで関連付けをしてるからJOINを使うほうが多そう。
  • エイリアスを付け忘れて中々エラー解決できずに泣いたのはいい思い出…。
    • ベンダーによっては必須ではないが、副問い合わせの結果には必ず別名を付けるのがよさそう。
  • これも複雑になるとあとで見直すとき大変なので、インデントやコメント大事だと思う。

まとめ

書籍では副問い合わせの検索結果が単一の値・1次元配列・表の3つにパターン分けした上で学習を行うよう章立てされており、参加者からも「理解しやすい」と好評でした。

参加者から多く出た意見としては、副問い合わせは便利な一方で可読性やパフォーマンスが落ちることがままあるため、使用方法やインデントに十分注意する必要があるというものでした。

副問い合わせは私自身も使う機会が多いのですが、やはり度々パフォーマンスが問題になったり構造が複雑なクエリになっていることがあるので、JOINやWITH句を用いることでより簡潔でパフォーマンスの良いクエリにできないか都度検討するよう心がけたいと思います。

次回は第8章「複数テーブルの結合」です。テーブルの結合はSQLの肝となる重要な機能なので、しっかりと学習を行いたいです。