『失敗から学ぶRDBの正しい歩き方』と『SQLアンチパターン』

「そーだい本」読んだよ！

失敗から学ぶ RDBの正しい歩き方

巷で話題の『失敗から学ぶRDBの正しい歩き方』(通称「そーだい本」: 以下、文字列長の都合でこの呼称を使用します)を読んだメモです。

Webアプリケーションを構築していく時、データの設計や運用の面で「こうしておけばよかったー」と後から悶々とする場面は多々あるんですが、本書はそれら現場のモヤモヤや失敗の数々に名前を付け、「アンチパターン」として断罪(！？)していく内容になってます。

元々は『SQLアンチパターン』という、よく似たコンセプトの素晴らしいオライリー本があるんですが、本書でも随所に言及があるので未読の方はまずそちらから手をつけるのがいいかもしれません。

ざっくりした内容はそれぞれリンク先の章立てを覗いてみてください。なんとなく雰囲気はつかめるんじゃないかと思います。

SQLアンチパターン

今回は両者を比べながらゆるーく感想を書いていきたいと思います。

両者の守備範囲

この2つ、まぁよく似た構成ではあるんですが、『SQLアンチパターン』の方がモデリングや発行クエリ等、主に設計・開発時の要素に焦点を当てていたのに対して、そーだい本は監視やバージョンアップ、バックアップといった運用時のあれこれにもフォーカスしていて、設計->開発->運用に到るまでのより広い範囲を扱おうとしている感じです。

また、前者『アンチパターン』に比べるとMySQLやPostgreSQLといった実際のRDBMSを題材に、それぞれの特性に踏み込んだ具体的な解説をしているのも「そーだい本」の特徴ですね。

従ってどのエピソードも記述が具体的で変な臨場感がありました(笑)
いつかどこかで見たような現場の「やらかし」がリアルに書き起こされてる感じなのですが、色々な現場を見てきた経験豊富な方ほど読み物としての没入感があるのではないかと思います。

これら失敗談の数々が妙にリアルで、個人的には他人の中二病エピソード聞かされて悶絶する感覚に近かったです。何回か「あーーーっ」てなりました。(後述)

アンチパターンに対する態度の違い

さて、両者とも同じく「アンチパターン」と銘打ってイケてない設計を糾弾していくのですが、このアンチパターンに対する態度には微妙に違いが見られます。

『SQLアンチパターン』の方は各章に必ず「アンチパターンを用いてもよい場合」という救済(?)の節が用意されていて、全てを悪と断罪している調子ではないのですが、「そーだい本」の方は「アンチパターンを生まないためには？」といった調子で、アンチパターンを踏み抜かないための回避策のみが用意されている感じです

一例を紹介すると、たとえば『SQLアンチパターン』の方で紹介された「第3章 IDリクワイアド(とりあえずID)」や「第11章 ファントムファイル」なんかは私も何度も踏み抜いているアンチパターンで、多くのプロジェクトで採用されている心当たりのある方も多いんではないかと思いますが、これらも「アンチパターン」として紹介されてます。

特に全てのテーブルにPKとして連番IDを付加する「IDリクワイアド」に至っては、今なお業界を二分する論争が現在進行形で続いている曰く付きの物件ですよね。
(もしご存知ない方がいれば `サロゲートキー` `ナチュラルキー` でググってみてください)

他方で「そーだい本」の方は「ノーチェンジ・コンフィグ」や「塩漬けのバージョン」など、「いやいやそれは...」と思えるような内容で溢れかえってます。

登場するアンチパターンの強度は全体的に「そーだい本」の方が強烈で、そうであるが故に適切な代替策が提示されているものと思いました。

「そーだい本」のハイライト

個人的に「ああああああああ」となったものをいくつか紹介します。
これらを見てみなさんもぜひ「ああああああああ」してください(笑)

第5章 「フラグの闇」(「とりあえず削除フラグ」)

Aさん: あぁ、これ全部のテーブルに削除フラグがついてるじゃん
Aさん: これだと、blogテーブルに削除されたデータが混在してて、どれが正しいデータなのかわからない……。確かに過去の編集履歴も持ってるけど、有効なブログを取り出すのにこんなSQLを書くのか……。

第15章 「簡単過ぎる不整合」

開発者A: ユーザが予約するとき、同伴者の情報も入れられるようにしといて。
開発者B: わかりました(同伴者テーブルを作るのは面倒だな。予約テーブルに絡む1つ追加するだけで良さそうだから、同伴者カラムを追加しよう)。
－－－翌日－－－
開発者A: あれ？このシステム、同伴者1名しか入れられないじゃん。3人まで入れられるようにしてよ。
開発者B: わかりました(昨日はそんなこと言ってなかったじゃん……、カラム追加するか)。

何が問題か
今回のパターンの一番の問題は、テーブルを分けたほうが良いことを理解しておきながらも、実装の都合を優先して非正規化したことです。

どうでしょうか？
特にこの15章の部分は個人的にかなりの破壊力でした。誰しも現場で何度となく目にしてきた光景で、身に覚えのあるエピソードなんではないかと思います。思考停止の横持ち、ｶｯｺﾜﾙｲ。

「そーだい本」は一事が万事この調子で、現場の「あるある」が並べ立てられていくのですが、それらに対して「ではどうすればよかったのか？」がきちんと提示されている点では非常に学びが大きかったです。

最後に

先述してきたように両者似た構成の本でありながら、扱う範囲も異なる相補的な内容になっていると思います。細かいテーマを挙げ連ねればキリがありませんが、いずれも読み下した範囲でそれぞれの性格をざっくり比較してみました。

どちらにも共通して言えることですが、現場で起こりがちな「失敗談」を元に解を提示していく構成なので、在野の経験が長い人ほど楽しめる(学びのある)内容になっているのではないかと思います。

個人的にはエピソード的な語り口から入る構成になかなかインパクトがあって、その臨場感も一つの「引き」になっていると感じました。

もし今後この手の本が出るとしたら、『カイゼンジャーニー』形式で一つのプロジェクトの設計から運用まで、通時的に現場の出来/不出来を追体験・解説するものが出版されたらすごく面白いんではないかと思いました。
つくろうかな！