• はじめに
• 本書を読む際の注意事項
  • 動作確認環境
  • 相関名を定義するAS
  • 本書に出てくる主要な人名
  • サンプルコードのダウンロード
  • 実行計画の取得方法
  • 本書の登場人物
• 初出一覧
• 目次

序章：本書を読むにあたってのSQLの基礎──モダンなSQLの必須技術，CASE式とウィンドウ関数

出会い

CASE式──SQLが誇る強力なユーザー定義関数

• CASE式の基本的な使い方──ラベルの読み替え
• 2つのCASE式の構文──単純CASE式と検索CASE式
• CASE式の注意点
• SELECT句でCASE式を使う──CASE式による行列変換（ピボット）
• UNIONで条件分岐するのは正しいのか
• WHERE句でCASE式──条件式の列を切り替える
• GROUP BY句でCASE式の列を参照する──アドホックな集計キー
• ORDER BY句でCASE式──任意の順番でソート
• UPDATE文でもCASE式──値をくるっと入れ替える
  • [colomn]実行計画の読み方

魔法のツール，ウィンドウ関数

• 累計とウィンドウ関数
• PARTITION BY句とORDER BY句の使い方
• ウィンドウとは何か
• フレーム句の使い方

まとめ

演習問題

第1章：サブクエリ・パラノイア──サブクエリの功罪

明細データの最小レコードを取得する

• 最後のレコードの値を取得する
• ウィンドウ関数を一般化してみる

株価のトレンド分析──直近の行との比較

• • [colomn]UPDATE対象テーブルには別名を付けられるか

列の折りたたみ

性能改善の重要ツール，インデックス

• 均一性
• 持続性
• 処理汎用性
• 非等値性
• 親ソート性

まとめ

演習問題

第2章：冗長性症候群──条件分岐をUNIONで表現するなかれ

UNIONで条件分岐するのは正しいか

• UNIONを使うと実行計画が冗長になりパフォーマンスが劣化する
• WHERE句で分岐させるのは素人

集計における条件分岐

• 集計における条件分岐もやっぱりCASE式

集約の結果に対する条件分岐

• UNIONで分岐させるのは簡単だが……
• 集約結果に対する分岐もSELECT句で

何をもってリレーションの属性とみなすのか

• 列で持つか，行で持つか，それが問題だ。

手続き型と宣言型

• • [colomn]CASE式はどこに書けるか？

まとめ

演習問題

第3章：ループ依存症──手続き型の呪縛を打ち破れ！

ループによる解法

• ループは正しい解なのか

ループからの脱出

• 更新におけるループ依存症
• WALのしくみとコミットの危険性
• ループを使うのは悪いことか
• 手続き型言語的な書き方（ループ）のメリット
  • 開発メンバーに高度なSQLスキルを要求しない
  • 性能が安定する
  • 性能の予測が簡単
  • トランザクションを細かく制御できる
• 手続き型言語的な書き方（ループ）のデメリット
• SQLにビジネスロジックを寄せる場合のメリット・デメリット

トレードオフを考える

• • [colomn]N+1問題

まとめ

演習問題

第4章：スーパーソルジャー病──すべての問題をやみくもにコーディングで解くべからず

SQLで解くか否か，それが問題だ。

• レベルの異なる情報を結合する方法
• SQL文の解釈順序にご注意
• 集約の単位には気を付けよう
• モデル変更で解く方法
• モデルを変更するときの注意点
  • 更新コストが高まる
  • 更新までのタイムラグが発生する
  • モデル変更のコストが発生する

注文ごとの件数を求める

• 再び，SQLで解くなら
• モデル変更で解く方法

属性を見抜く力

すべてをSQLで解くべきか

• 初級者よりも中級者がご用心
• データモデルを制す者はシステムを制す
• 戦術より戦略
  • [colomn]データ同期の難しさ

まとめ

演習問題

第5章：時代錯誤症候群──進化し続けるSQLに取り残されるな！

繰り返されるサブクエリ

• 共通表式

CASE式

言語の進化とエンジニアの進化

SQLは寿命の長い言語か？

• 自らを大きく変化させてきたSQL

時代錯誤症候群は冗長性症候群を併発する

• 冗長さはコードをわかりにくくする
• 比較できるのは列だけではない──複数列への拡張

良い新機能と悪い新機能

• • [colomn]SQL周辺系機能の標準化

まとめ

演習問題

第6章：ロックイン病──実装依存の罠にはまるな！

• • [colomn]アンチパターン：テーブルの継承

擬似配列テーブルに遭遇してしまったら

SQLにおけるJSONの扱い方

文字列型の仕様がバラバラすぎて困る件について

標準ではないTEXT型の仕様もバラバラ

隠れロックインにご注意

まとめ

演習問題

第7章：SQLグレーノウハウ──毒と薬は紙一重

単一参照テーブル──テーブルにポリモフィズムは必要か

列持ちテーブル

• 入力側の理由：ついつい列を配列に見立ててしまう
• 出力側の理由：出力レポートが列持ち形式の場合

集計用のキー列をテーブルに持つべきか

サロゲートキー VS ナチュラルキー

シャーディング

• • [colomn]パーティションとインデックス

データマート

隣接リストモデル──古のデータモデルの復権

グレーノウハウのほうがアンチパターンより判断が難しい

• • [colomn]再帰と入れ子集合

まとめ

演習問題

第8章：集合指向アレルギー──なぜSQLはエンジニアにとってわかりにくいのか

HAVING句による集合の条件指定

• 自己結合をHAVING句によって置き換える

HAVING句の力──四角ではなく円を描け

SQLの七不思議──NULLはSQLの鬼門だが便利なトリックにも使える

• • [colomn]スロークエリのキャプチャ方法

まとめ

演習問題

第9章：リレーショナル原理主義病──ウィンドウ関数は邪道なのか

LAGとLEADによる行間比較

開始地点からの差分の計算

UPDATE文でもウィンドウ関数──NULLの埋め立て

リレーショナル原理主義派との闘い

まとめ

演習問題

第10章：更新時合併症──冗長なサブクエリ，性能劣化，実装依存

更新における冗長なサブクエリ

• 代入式への行式の拡張
• シンプルさは常に良い
• 残念なお知らせ
• SET句は更新対象を制限しない
• WHERE句で更新対象を制限する

更新におけるウィンドウ関数

• SET句でウィンドウ関数を使えるか？
• SET句でのウィンドウ関数の威力
• 残念なお知らせ
• SET句でウィンドウ関数を使う条件

自己参照テーブルの削除

まとめ

• • [colomn]SQL七不思議

演習問題

第11章：ライトスタッフ──正しい資質

ロバート，データベースエンジニアについて語る

AI時代のデータベースエンジニア

第12章：演習問題の解答

• あとがき
• 索引