第1章　SQL再入門

• エピソード1　SQLは集合指向の言語と心得よう
  • 1.1　本番システムの商品一覧画面が遅い！
  • 1.2　原因はアプリ側でデータ集計を行っていたこと
  • 1.3　なぜアプリ側でSQL発行ループを書こうとしてしまうのか？
  • 1.4　SQLは「集合指向」言語です
  • 1.5　役割分担が適切にできていない
• エピソード2　SELECT文はカタマリを切り出す形でイメージしよう
  • 2.1　SQLで大事なのは「表形式のカタマリを操作する」イメージ
  • 2.2　表形式のデータ操作イメージを持つとは
  • 2.3　表形式のデータ操作イメージを描く方法
• エピソード3　結合条件と抽出条件の違いとは
  • 3.1　ON句の本当の意味が知られていない？
  • 3.2　SELECT処理の流れをイメージしよう
  • 3.3　結合条件と抽出条件を区別する
  • 3.4　OUTER JOINのWHERE句で内部表側のカラムを使っていたら要注意
  • 3.5　再び，SQLはイメージで考えよう
• エピソード4　複雑な場合分けロジックもCASE式で一発解決！
  • 4.1　月末の会員情報更新処理，どうしよう？
  • 4.2　テーブルを全件走査するUPDATEは減らしたい
  • 4.3　条件項目更新型UPDATEの分割実行に注意
  • 4.4　CASE式とパラメータテーブルを活用する
  • 4.5　会員ランク更新処理を実装しよう
  • 4.6　集計と更新の一発化はできない？
  • 4.7　CASE式はSQLに小回りの効く記述力を与えてくれる
• エピソード5　ExcelでSQL操作のイメージをつかむ法
  • 5.1　正しい理解には現実世界のイメージを持つことが大事
  • 5.2　複雑な場合分けをパラメータで処理
  • 5.3　CASE式にパラメータテーブルを組み合わせる
  • 5.4　2万ステップのJavaがたった3つのSQLに？
  • 5.5　Excel計算式でSQL感覚をつかむ法
• エピソード6　「INよりEXISTSが速い」神話の真実と相関サブクエリ
  • 6.1　INとEXISTSの違いを見極めるポイントとは
  • 6.2　選択性の高低を意識してINとEXISTSを使い分けよう
  • 6.3　INとEXISTSの処理の流れをつかもう
  • 6.4　しくみを理解して相関サブクエリも使いこなそう

第2章　SQLとデータベースのしくみ再入門

• エピソード7　データベースがSQLを処理する流れを理解する
  • 7.1　「ループ」が引き起こす3つの問題
  • 7.2　DBとAPの役割分担を考えるための見取り図
• エピソード8　実行計画で実際のアルゴリズムを把握しよう
  • 8.1　ぐるぐる系SQL，使っていませんか？
  • 8.2　しくみを理解せずに使えば一発系も遅くなる
  • 8.3　実行計画の確認はSQLチューニングの基本！
• エピソード9　インデックスが効くときと効かないときの違いとは？
  • 9.1　自分が教える側になれば一番よく勉強できる
  • 9.2　インデックスがない検索はなぜ遅い？
  • 9.3　インデックスが効くと無駄なページを読まずに済む
  • 9.4　「しくみ」がわかっていないと真の応用は利かない
• エピソード10　JOINのアルゴリズムを理解する
  • 10.1　SQLから「逃げる」ほど問題は悪化する
  • 10.2　3種類のJOINアルゴリズム
  • 10.3　SQLはしくみを理解して使うことが重要
  • 10.4　回避できるデメリットはデメリットではない
  • 10.5　JOINを使うと高コストになる？

第3章　アプリケーションとデータベースの役割分担

• エピソード11　データベースで集計するほうが低負荷になる
  • 11.1　SQLで集計をすると処理を分散できない？
  • 11.2　DBで集計したほうが低負荷になる理由とは
  • 11.3　負荷はピークではなく面積で考える
  • 11.4　低い階層の動作イメージを持つことが重要
• エピソード12　「スケールアウトしにくいからJOIN禁止」という間違った考え方
  • 12.1　開発元がギブアップしたシステムの改修依頼
  • 12.2　バッファプールが「ぐるぐる系」に影響しない理由とは？
  • 12.3　スケールアウトしにくいからJOINを禁止する？
  • 12.4　マスタ系データをコピーする方法
  • 12.5　JOIN禁止はかえって負荷を増やす
• エピソード13　NoSQLはRDBのサブセット？
  • 13.1　大は小を兼ねる……わけではない
  • 13.2　RDBが登場した理由
  • 13.3　NoSQLが登場した理由
  • 13.4　RDBとNoSQLの使い分け

第4章　間違ったデータベース設計とそれを修正するアイデア

• エピソード14　インジェクション対策のためにもSQL動的組み立ては避けよう
  • 14.1　任意条件の検索機能を作りたい
  • 14.2　SQLの動的組み立てはSQLインジェクションに弱い
  • 14.3　パラメータクエリでインジェクション回避
• エピソード15　Entity-Attribute-Value手法はやめよう
  • 15.1　使い物になる技術知見の広め方
  • 15.2　根強く使われているEAVアンチパターン
  • 15.3　EAVを使いたくなる3パターン
  • 15.4　RDBの得意分野を正しく理解して使おう
• エピソード16　EAVや非正規形のテーブル設計を少しずつ修正する方法
  • 16.1　EAVのコードはメンテナンスしづらい
  • 16.2　EAVの名称マスタを少しずつ移行する方法
  • 16.3　非正規形のテーブルを正規化したい

第5章　開発を効率よく進めるためのアイデア

• エピソード17　SQLのための仕様書は書くだけムダ
  • 17.1　書類を増やしたからといって役に立つとは限らない
  • 17.2　SQLは人間が現実世界で使う言語に近い
  • 17.3　SQLは「要求」レベルを記述する言語
  • 17.4　SQL自体が仕様書のようなもの
• エピソード18　O/Rマッパーを使うべきか・使わないべきか
  • 18.1　O/Rマッパーで起きがちなN＋1問題とは
  • 18.2　O/Rマッパーを使っていいとき・悪いとき
  • 18.3　SQLは考え方さえわかれば簡単な言語
  • 18.4　インピーダンス・ミスマッチとは？
  • 18.5　SQLを理解してO/Rマッパーを使うなら問題はないが
• エピソード19　テーブル設計の変更で大きな手戻りを発生させない方法
  • 19.1　新規開発やりますよ！
  • 19.2　「テーブル設計は後まわし」の真意とは？
  • 19.3　インターフェース仕様書を書いてスタブ自動生成
  • 19.4　DBアクセスをAPI化する「APIファースト開発」
• エピソード20　データベース担当とアプリ担当は分けたほうが良い
  • 20.1　ベテランSEでも意外にRDBとSQLのことは理解できていない？
  • 20.2　プログラマは交換可能な部品扱いだった
  • 20.3　DB担当とAP担当は分けたほうがいい
  • 20.4　担当を分けてAPIファースト開発を！