SQLクックブック第2版の技術監修を担当した

• SQLクックブック第2版が発刊された。
• 書籍の対象読者とそうではない人をまとめた。
• 技術監修を担当したので役割と作業内容をまとめた。
• 作業を通して学んだことをまとめた。

SQLクックブック第2版¹は、2007年に出版されたSQLクックブック²の改訂版だ。原著は英語で出版されており、原著の第2版³は2020年に出版された。今回の書籍はこれの翻訳版である。

SQLクックブックの内容には次のような特徴がある。

• 問題とその解決策を提示し、それを解説している。
• 複数のデータベースについての説明がある。
• 設定されている問題の数が多い。
• 絵や図は極めて少ない。
• データベースに関する基本的な用語などの解説はほとんどない。
• SQL以外のプログラミング言語⁴は登場しない。
• データベースの運用や実装についての記述はほとんどない。

この特徴を元に対象読者と対象ではない人を整理した。

部署(dept)と従業員(emp)のテーブルと初期データ⁸は事前に与えられ、データ操作を行う。取り上げられるデータ操作は、従業員数の取得のような基本的なSELECT文、面倒な文字列や日付の操作、ウィンドウ関数を用いた複雑な集計など様々だ。付録ではウィンドウ関数とCTE(共通テーブル式)について解説されている。トピックは章ごとに仕分けられている。以下は各章とそのタイトルだ。

各トピック流れは、まず問題を挙げ、次に各種データベースでの解決策、次にそれらの解説といった流れで記述されている。解決策と解決は各種データベースについて言及があるものもあれば、トピックによっては解決策がそもそも存在しないものも一部ある。更に詳しい内容はオライリージャパン社のSQLクックブック第二版の書籍ページ¹で確認できる。

今回の書籍は原著が存在する。そのため技術監修としては原著を崩すことなく、内容として間違いがない状態にするということを求められる。手法はさまざまだが、明らかにおかしい箇所や一貫性の観点で著しく崩れている箇所は修正するがそうでない箇所については原著を尊重する。

例えばSQLのキーワードの記述はは大文字か小文字のどちらにするかとか、SQLの改行位置やインデントの位置などは原著をできるかぎり尊重している。またその他のこちらで巻き取れるところをやっていく。検証環境の整備や、作業上のルール化、サポートページなんかもそれにあたる。

参考までに実際のコミット状況を掲載する。

私の主な作業内容を月毎にまとめた。本格的に監訳作業を開始したのは2021年05月からだった。それよりも前は翻訳が済んでいないので比較的のんびりとしていた⁹。事前準備では原著を元に必要な検証環境や、Githubリポジトリ等必要なリソースを整備した。議事録を見返すとYoutubeチャンネルを解説しようなんていう話も挙がっていていた¹⁰。

今回の検証環境は5種類のデータベースであったためそれらを整備した。Oracle以外はDockerイメージがあるのでDockerを利用した。OracleについてはDockerイメージはなかった。しかしソースコードとDockerイメージをビルドする方法は提供されていた。それを利用してDockerイメージをビルドした。

検証環境を含め多くの作業でEmacsを利用している。Emacsにはデータベースユーティリティが用意されている。デフォルトの設定ではローカル環境にデータベースクライアントが存在することを期待している。今回データベースサーバーはDockerで起動している。もちろんlocalにデータベースクライアントをインストールすることもできるが、クライアントはデータベースサーバー内に既にあり docker exec で入ってしまえば接続設定を多少省略できる。そのため docker exec でコンテナに入る形でEmacsのデータベースユーティリティを利用できるように整備した¹¹。

作業を停滞させない為に定例会議を実施した。定例会議があると、それまでに自分で設定したノルマを達成しようと作業に取り組むため、作業が進まず困るということが無くなる。以前はオンラインではなくオフラインでの打ち合わせをお願いしていた。だが今回はコロナ禍という事もあり、オンラインでの打ち合わせとした。今までの他の本の監修作業を行う場合にも、編集者の方に願いして実施して頂いている。

主な内容は以下のような内容だ。

• 頻度は週1回。
• 時間は1時間。
• 曜日時間は固定。

• 以下の内容が議題。

  • 進捗報告。
  • 困っている事の共有と対応の決定。
  • その他、雑談など。

データベースはWeb系のバックエンドを実装していると必ず扱う。O/Rマッパーを用いてデータベースへアクセスすることも多いか、発行されるSQLを意識して実装するのとそうでないのとではちがった実装になる。O/Rマッパーによって発行されるSQLを考えていないと、N+1問題を起しがちだ。そういったコードはリファクタリングもしにくいし、パフォーマンスチューニングも難しくなる。データベースが得意なことはデータベースに行わせるのがよい。そういった意味でもSQLを書く力は必要になる。SQLクックブックはSQLを書く力を高めるための教材としてはとてもよい書籍だと思う。

またSQL自体は一度覚えてしまうと息の長い技術的要素だ。たとえば今Ruby on RailsのWebアプリケーションを書いていたとして、3年後もRuby on Railsを書いているだろうか。もちろん書いているかもしれない。でも、もしかしたらPythonに転向しDjangoを使っているかもしれない。GoでAPI Serverを実装しているかもしれない。ただそれらの場合でもきっとRDBMSを使っている(使っていないかもしれないけれど)。

Webアプリケーションフレームワークやプログラミング言語を学ぶことも重要だが SQLを学ぶ重要性はそれと同等かそれ以上に高いと感じた。

今回私は技術監修という立場で制作に参加した。とても名誉なことだと思う。この素晴しい機会を与えてくださった株式会社オライリー・ジャパンの皆様、出版に関った方々に感謝している。特に担当編集者の方には大変お世話になった。今回に限らず毎度お世話になっているといった方が正しいかもしれない。ご自身の編集者としての作業の傍ら、私の作業が滞らないように管理しその都度必要な助言やサポートをしてくださった。

私個人としてはとても得るものが多い書籍だった。そしてデータベースやデータについて、また仕事や作業のやり方など考えることが多かった。ぜひデータベースやデータについて考えてくれる人が増えて欲しい。そのきっかけが私の関った書籍であったなら本当に素敵なことだ。それではまたどこかの勉強会で。