毎日何かを学習し、Noteに進捗報告する！のリスペクト(という名のパクリ)カレンダー、4日目です。

  買ったはいいけど全く手を出していなかった「プログラマのためのSQL 第4版」を紐解きました。

  現在の業務は、いわゆるBI(Business Intelligence)に関する仕事が主であり、SQLは欠かせません。一方で、基幹システムのような複雑なテーブル同士の制約を考慮した設計など、離れてしまっている分野も少なくないので、一度きちんと再学習しようと思い、読むことにしました。

  なるほど。わかるようでわからない内容が続いています。

巻末の「翻訳・監修を終えて」で、訳者のミック氏はこう書いています。
  「どうせこの本も大したこと書いてないだろう」とたかをくくって読み始めた最初の感想は、次のようなものだった。

何が書いてあるのか全然わからないんですけど。

  いや、本当に参った。よくチンプンカンプンな本について「理解できるところの方が少ない」という言い方をするが、まさにその状態を地でいっていたのだから。しかし理解できた数少ないパートに関して言えば、「これは極めて重要なことが書いてある」というのが感想だった。つまり私にとって本書は「非常に重要で目から鱗が落ちる」と「まったく意味不明」がないまぜになった奇妙な本として現れたのだった。(P.780)

  僕自身はミック氏ほどSQLやデータベースに関する知見があるわけでありませんが、言わんとしていることは、よくわかりました。本書は章ごとに独立した内容で、どの章から読んでも問題はありません。そこで、訳者が前書きで「本書の中で最も重要な章は？」という問いに対する回答である「第13章 NULL:SQLにおける失われたデータ」を読みました。

  結果、前述の感想を抱きました。

  NULLが忌み子に近いSQLにとって望ましいものではないということはよく伝わりました。一方で前半部のNULLと論理などを正確に理解しないと、NULLを回避するための設計の重要さなどを完全に腹落ちさせることは困難であることも伝わりました。まだ前半が正確に噛み砕けていません。

  実際の現場では、NULLを取り扱わないデータベースはおおよそ存在しません。そのため、本章の内容が完全に現場で適用できるわけではないでしょう。しかし、理論的な意味で望ましくないことを知っておくことは、正しい設計の指針を得る上で、重要です。

  「第5章 基底テーブルとそれに関連する要素」は制約をどのように使うかを主に書いており、難しくも理論的に有益なことが書いてあるように感じました(つまり、まだ正確には噛み砕けてはいないということです)。制約を用いることでデータに関する仕様のチェックができるのは理解できます。しかし現実には、パフォーマンスの都合や仕様変更に関する問題から、DB側でなくフロント側やバックエンドプログラム側でチェックが行われることが多いです。

  本書はSQLを深く理解するには非常に良書ですが、実際の現場でどのように適用するのかは改めて検討するべきでしょう。幸いなことに、訳者のミック氏により本書には

現場のエンジニアとして、訳者は今後も度々、訳注において、物理的制約に起因する夢のない話を補いたい。(P.70)

と、要所要所で訳注がついてます。ミック氏の訳に感謝です。

  現在は「第9章 正規化」を読んでいます。情報処理技術者試験のデータベーススペシャリストで正規化についてはだいぶ学んだつもりですが(とはいえもう15年近く前ですね…)、反射律や増加律、合弁律などの馴染みのない言葉もあり、理解に時間かかっています。ともあれ、あせらずに今後も少しずつ読み進め、理解を進めていきます。ちゃんと読破できますように。