SQLの苦手を克服する本 データの操作がイメージできれば誰でもできる (Software Design plusシリーズ)
- 技術評論社 (2019年8月26日発売)


- Amazon.co.jp ・本 (248ページ)
- / ISBN・EAN: 9784297107178
作品紹介・あらすじ
本書は、SQLの文法は学んだもののSQLに苦手意識を持っているITエンジニアのための書籍です。
複雑なSQLを読める/書けるようになるには、データベースの表をカタマリで操作する考え方(集合志向)を理解する必要があります。本書では、「データベースの表をカタマリで操作するイメージ」を持てるように、文法の解説はいったん脇に置き、どのようにイメージすれば良いか、ほかの手続き型言語とどう違うか、というポイントを豊富な図を使って入念に解説します。
また、SQLやデータベースで起こりがちな性能、メンテナンス性、開発効率などの問題を解決するには、データベースのしくみを理解し、アプリケーションとデータベースの役割を適切に分担する必要があります。こちらについても、さまざまな図と例を使って、問題が起きるメカニズムと解決のアイデアを紹介します。
感想・レビュー・書評
-
SQLをどうすれば真価を発揮できるかについて書いた本。
そもそも、一般的なプログラミングは手続き型に則っているのにたいし、SQL(というより、リレーショナルデータベース)は集合思考なもんだから、ベテランのエンジニアでも理解していない人がいるらしく、ぐるぐる系SQLだとか効率の悪いSQLを書いてしまう人もいるらしい。
そういえば前にいたなぁ。JAVAについてはかなり詳しいのだけど、SQLについて苦手意識がある人。ある程度、勉強したことはあるので、文法は分かっている(例えば、LEFT JOINした項目をWHERE文で使うのがおかしいというのは分かる)のだけど、ぐるぐる系のほうがいいとか言っちゃう。JOINもやりたがらないし、UNIONもやりたがらない(UNIONした後にORDER BYしたら楽なのに、なぜJAVAでソートしなきゃいけないのかと……)。正直、そういう人にこの本を読んでほしいと思った。
ただ、もちろん中には自分も知らないことが書いてあって、「ON a.B_ID = B.ID AND 0 = B.DelFlag」という結合条件でJOINをかけると、1対1関係にある(同じIDがどちらにもある)テーブルだと、INNER JOINでもLEFT JOINでも結果が同じになると書いてあって驚いた。てっきり、LEFT JOINでも、B.DelFlagが1のデータはNULLになるだけかと。ちょっとどこかで試してみたい。
それと、IN(サブクエリ)とEXISTSの違いとか。処理される順序がINとEXISTSで違うのだとか。サブクエリで返ってくる結果が少ないのであれば、INを使ったほうがいいらしい。覚えておきたい。
後、時々、複数の種類の名前と値を一つのマスタにしているテーブルを見るけど、あれはEAV(Entity-Attribute-Value)というらしく、SQLアンチパターンらしい。やっぱりあれって、SQLのアンチパターンなのか。確かに便利だなと思ったのだけど、ちょっとした違和感は確かにあった。
著者はAPIファースト開発という手法を提案しているそうなのだけど、ようはストアドプロシージャを使った開発と考えていいのかな? うちの会社でも基本、自社開発だとそうしてるし、そのほうがストアド変更するだけでアプリの変更はいらないという修正依頼も多いので、確かにいいと思う。詳細をみるコメント0件をすべて表示 -
SQL初心者はこの本を読むと概要がクイックに理解できる。おすすめ
-
タイトルからして初心者向けのSQL本かと思ったが、DBの内部の話まで書かれており勉強になった。また、題材が実際の業務にありそうなものが多く好印象。
APIファースト開発については個人的にはストアドに頼りすぎるとデバッグが困難というイメージが強く採用したいかと言われるとあんまりという印象。 -
開発現場の実情に寄り添った形で、会話形式をベースに解説しており、頭に入ってきやすかった。
■個人的に参考になった点
・INとEXISTSの使い分け…選択性の高低を意識する
・DB性能への影響要素
・DBアクセスのAPI化…DBもインターフェース仕様書を書こう -
生島氏はその挑発的な発言ゆえネットではあまり評判の良い人物ではありませんが、この本はマトモです。内容はどれも開発者なら当然知っているべきことばかりですが、こうしてまとまって本になっていることに価値があります。類書もあまり見たことがありません。現場あるあるに絡めた会話形式も読みやすいです。それは共著者の開米氏の力でしょうか。良書と思います。
ただし、5章はポエムです。無邪気にDB設計後回しストアド採用などしたら危険すぎます。DOAの思想はいささか古びてはおりますが、今でも軽んじるべきではありません。また、ストアドはクラサバ時代に多くの人が痛い目見てます。それは元コボラーの開発者がSQLを理解できないからではありません。
ひょっとするとクラウド時代のノーコード・ローコード開発はAPIファーストに近いものかも知れませんが、別物です。