2013/07/19

[書評]アート・オブ・SQL

見識の浅い私が書評だなんておこがましいにもほどがあるんですが、それっぽいことを書いてみたくなったので書いてみました。

この本を読み始めた直後に「プログラマのためのSQL 第4版」が発売されました。
読みかけでほっぽりだすのも気が引けたので「プログラマのためのSQL 第4版」は積読(つんどく)にしてこの読書感想文を書いています。

なにせ私は本を読むのが遅くて困ります。


.

書籍情報

邦題 :アート・オブ・SQL -パフォーマンスを引き出すSQLプログラミング手法-
原題 :The Art of SQL
発行所:オライリー・ジャパン
発売元:オーム社
著者 :ステファン・ファラー、ピーター・ロブソン
訳者 :木下哲也、有限会社福龍興業
発行日:2007/09/12
ISBN 978-4-87311-336-4



「木下哲也、有限会社福龍興業」の組み合わせは同年1月発行の「SQLクックブック」の訳者でもあります。




タイトルと章立て

「アート・オブ・SQL」は原題の「The Art of SQL」をほぼそのままカタカナにしてるんですが、
この本は「孫子」の「兵法」の英題「Art of War」に着想を得て書かれており、名前もそれに由来しています。
つまりこの「アート/Art」は「芸術/美術」ではなく「技巧/戦略」を意味しています。

実際、章立ても「兵法」の章立てと似通っており、「計画の策定(兵法:計篇)」に始まり「スパイの利用(兵法:用間篇)」で締めくくられているのも面白いですね。(もちろん、こじつけっぽいところがないわけではないですが)

アート・オブ・SQLの章立て

1章 計画の策定
パフォーマンスのためのデータベース設計方法を検証します。
2章 戦争の実施
データベースに効率的にアクセスするためにはプログラムをどのように設計すべきかを説明します。
3章 戦術的な配置
インデックスを付ける理由と方法を説明します。
4章 策略
SQL文の策定方法を説明します。
5章 地形
物理的な実装がどのようにパフォーマンスに影響するかを示します。
6章 9つの状況
古典的なSQLパターンとその取り扱い方法を取り上げます。
7章 戦略のバリエーション
階層データの扱い方を説明します。
8章 弱みと強み
いくつかの困難な状況の認識方法と対処方法に関する示唆を提供します。
9章 複数の戦線
並列処理に取り組む方法を解説します。
10章 戦力の終結
大量データに対する対処方法を扱います。
11章 計略
不適切なデータベース設計を切り抜けるのに役立ついくつかの秘訣を示します。
12章 スパイの利用
本書の締めくくりとしてパフォーマンスの定義方法と監視方法を説明します。
(以上 本書P.vii より引用)


兵法の章立て

計篇
序論。戦争を決断する以前に考慮すべき事柄について述べる。
作戦篇
戦争準備計画について述べる。
謀攻篇
実際の戦闘に拠らずして、勝利を収める方法について述べる。
形篇
攻撃と守備それぞれの態勢について述べる。
勢篇
上述の態勢から生じる軍勢の勢いについて述べる。
虚実篇
戦争においていかに主導性を発揮するかについて述べる。
軍争篇
敵軍の機先を如何に制するかについて述べる。
九変篇
戦局の変化に臨機応変に対応するための9つの手立てについて述べる。
行軍篇
軍を進める上での注意事項について述べる。
地形篇
地形によって戦術を変更することを説く。
九地篇
9種類の地勢について説明し、それに応じた戦術を説く。
火攻篇
火攻め戦術について述べる。
用間篇
「間」とは間諜を指す。すなわちスパイ。敵情偵察の重要性を説く。
(以上 Wikipedia「孫子」 より引用)


対象読者

簡単に言うと「中級者以上」です。
  • SQLデータベースの開発経験がかなりある開発者(1年、またはできればそれ以上の年数)
  • 上記の開発者の管理者
  • かなりのデータベース要素を使ってプログラムを設計するソフトウェア設計者
(以上 本書P.vii より引用)
「データベース管理者(特にデータベース開発をサポートするDBA)は念頭においていない」と明言しています。

また、前提条件として以下のようなものも挙げられています。
  • すでにSQL言語を使ってデータベースアプリケーションを開発したことがある。
  • インデックスについて考えたことがある。
  • 5000行のテーブルを大きなテーブルとはみなさない。
  • 1つのコンピュータ言語とコンピュータプログラミングの原則に精通している。
  • すでに各所でダウンしたことがある。
  • 遅く貧弱なパフォーマンスのシステムに対するユーザーの不平を聞いたことがある。

私の場合ふるいから零れ落ちそうですが、(特に「プログラミングの原則に精通」とか)まぁなんとか読み通せました。

なお、内容はほとんどの場合「自分でSQLを書く」ケースを前提としているため、O/Rマッパーしか使わない人にはあまり役に立たないでしょう。
まぁそんな人はこの本を手に取らないでしょうけど。



目的

序章にも書いてあるのですが、この本の目的は「SQL文を学習すること」でも「ある問題に対処するための具体的方法を示す」ものでもなく、「戦略を知っておくことで様々な困難な状況に対応したり、困難な状況の発生を防止できるようになる」ところにあります。
いろんなところに引き出しを作っておくのは大事ですね。
また、「時には残念なコードをかかなければならない」ことも必要としており、理想論ではなく現実的です。



ポイント

ここから先は私が個人的に「!」と思ったポイントをピックアップして紹介してゆきます。


第1章 計画の策定

この中で「リレーショナルモデル」について解説されています。
「リレーショナルモデル(関係モデル)」については説明が困難で、多くのSQL本ではわずかに触れる程度か避けて通っている印象があります。また場合によっては完全に誤解していることもあるのも事実です。
この本では「リレーショナルモデル」の理解が戦略に必要と捉えていて、わずかなページ数ではありますがそれなりに説明をしています。
またこの章ではNULLの取り扱いについても解説があり、NULLの存在について比較的肯定的な立場を明言しています。ラムズフェルド国防長官の言葉(「既知の既知」「既知の未知」「未知の未知」)の引用は面白いですね。


第7章 戦略におけるバリエーション

このなかで「SQLデータベースでのツリーの表現」というやっかいな課題を解説しています。
具体的な実装パターンとして以下の4つの名前で挙げています。
  • 隣接モデル
  • 実体化パスモデル
  • ネスト化集合モデル
  • ネスト化間隔モデル
このうち、前者3つについての具体的な実装方法も表付きで紹介されているのですが、それぞれメリット・デメリットがあり「最良な表現方法はない」としています。
4つ目の「ネスト化間隔モデル」については「将来的には有望に見えるが実装は困難で最速の方法ではない」として実装方法の解説はされていません。

余談
私の場合「RDBでツリー構造を表現」と聞いて最初に思い出すのがミックさんの「リレーショナルデータベースの世界」です。

この「リレーショナルデータベースの世界」で「SQLで木と階層構造のデータを扱う」として紹介されているのは以下の3つです。()内はアート・オブ・SQLでの名前
  • 入れ子集合モデル (ネスト化集合モデル)
  • 経路列挙モデル (実体化パスモデル)
  • 入れ子区間モデル (ネスト化間隔モデル)

アート・オブ・SQLでの「隣接モデル」については「入れ子集合モデル」の解説の中で、「隣接リストモデル」と言う名前で「従来」の方式としてごく簡単に紹介されています。

ツリーの表現についての感想や私見を書き始めると終わらなくなってしまうのでここでは割愛します。


第10章 戦力の集結

「ビッグデータ」という言葉が流行る前の書籍なのでその言葉は出ませんが、いわゆる構造化された大量データをRDBMSでどう取り扱うかという問題を扱う章です。
この本は全般的に第3正規形以上で設計する前提で書かれているのですが、ここではDWHにおける「ディメンションモデリング」についてページを割いて解説されており、(ディメンションテーブルにおいての)非正規化の有益性も説かれます。
私自身ちょうど仕事でDWHのRDBMSの検討を行っていたのでリアルに勉強になりました。



全体を通して

パフォーマンスの話が多いこともあり、実際の製品でのベンチマーク比較を少し抽象的にしたグラフを載せています。
製品名は書いてあることもありますが、製品のバージョンやハードウェアのスペックなどは明かさず、より一般的な話として読ませる工夫がうかがえます。

具体的に出てくる製品名は Oracle, DB2, SQL Server, MySQLあたりです。
標準SQLにこだわらずに製品ごとの機能やSQL方言を有効に活用することに躊躇はありません。

「翻訳が直訳っぽくなっているんじゃないかな」と思わせる箇所がいくつかあります。
だから不満というほどではないですが、わがままを言えば同じ品質で通して欲しいですね。

中級者以上向けなので敷居は高いですし銀の弾丸にはなりませんが、多岐にわたり情報が詰まっており、知らなかった引き出しを発見できる一冊だと思います。




さぁ次は「プログラマのためのSQL 第4版」を読むぞ。


.

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。