「SQLアンチパターン」。監訳者 和田卓人氏自身による書籍紹介

アンチパターンに名前を付けることで、コンテキストを共有できて議論がしやすくなる。2月14日、15日に都内で開催されたイベント「Developers Summit 2013」、通称デブサミにおいて、書籍「SQLアンチパターン」の監訳をした和田卓人氏は本書の意義をこう強調しました。

「SQLアンチパターン」は、データベースにおける設計からアプリケーションに関わるレイヤまで、開発者が陥りやすいミスや誤解に名前を付けたうえで原因と解決策を詳しく解説しています。

和田氏が指摘するように、これまでデータベースに関するデータ設計などのミスを指摘したり議論するには、その背景を共有するための面倒な説明が必要でした。SQLアンチパターンの登場は、そうした背景を暗黙のうちに共有する手段を与えてくれることになります。本書はデータベース分野の古典になる資格を十分に備えているのではないでしょうか。

書籍の監訳者自身が書籍の内容を紹介したセッションの概要を、紹介しましょう。

25のアンチパターンを4つに分類

和田卓人氏。

このセッションでは、この本「SQLアンチパターン」の紹介をしていきます。この本には25のアンチパターンが出てくるのですが、全体が4つの部に分かれています。

論理設計の部には8つのアンチパターンが出てきます。時間がないのでひとつひとつは説明しませんが、Rails界隈がざわざわしたのは3の「IDリクワイアド」で、これは考えなしに「テーブルにはIDがあるものなのだ」と、IDをつけてしまうこと。IDがいけないのではなく、考えなしにつけてしまうことが問題です。

物理設計の部には4つ。金額にFloatやDoubleを使ってしまう9の「ラウディングエラー」。11の「ファントムファイル」は、動画などのデータはファイルとして保存し、そのパスをデータベースに入れるというパターンですが、「ファイルとはデータベースの外に置くもの」と固定的に考えるのがアンチパターンなんですよ、というのがこの11です。

クエリの部には6つのアンチパターンがあります。

アプリケーションの部のアンチパターンは7つ。このあいだTwitterがクラックされたという話題があって、HashとSaltだから安全ではという議論がありましたが、パスワードを平文で保存しているのがなぜ悪いのか、というのが19。

20はたぶん最大のアンチパターンであるSQLインジェクション。

25は原書にはないのですが、日本の読者のためにプレミアムな一章をと、奥野さん（@nippondanji）に頼んで、快く引き受けてくれたのがこの25です。

名前だけで何をやらかしたか分かる

アンチパターンとはなんなのか。

よかれと思ってやったんだけれど、裏目に出てしまう、起こってしまう事柄と技法のことを、アンチパターンと呼んでいます。この本が優れているのは、べからず集、あるある集だけではなく、禁を破っていいときのこともちゃんと書かれているところです。

なんでアンチパターンの名前が全部カタカナなのかというと、口に乗りやすいパターン、共有されやすいパターンを考えたとき、やっぱりカタカナだなと。カタカナは異色で、目立つ要素を持っています。

名前だけで、何をやらかしたのかが分かるのがいいところ。コンテキストや背景といったものを名前で共有したい。

例えば「ナイーブツリー」。これを「素朴な木」っていうと会話の中に混ざってしまう。「これはナイーブツリーだからイカンだろう」って会話の中で目立ってほしい。

QA@ITのコメント欄やスラドとかツリー構造になっていると、ベテランは「あ、ツリー構造」と思うわけです。そしてツリー構造とRDBは相性が悪くていつも悩まされるんです。

このとき、こういう作り方をした人はいますか？ （会場の6割くらいの手が上がる）。

これの何がいけないかというと、どれだけ深くなるか分からない。すごい炎上するコメント欄があったりして、どれだけ深くなるか分からないときには、これでは扱えないんです。素朴すぎる。

アンチパターンの見つけ方として、この本で書かれているのは、典型的な台詞が出ててくることです。例えば「このツリーは何階層？」といった台詞が出てくると、それはアンチパターンの匂いがします。

しかし使っていい場合もあります。例えばPostgreSQLやDB2のように共通テーブル式（CTE：Common Table Expression）を使って再帰クエリが使えるデータベースがあります。この場合は使っていい。一概に親idを持つのが完全なアンチパターンというのではないと（追記：Oracleは独自構文で再帰クエリを記述可能。11g R2からは共通テーブル式も利用可能とのこと。本文の一部を修正しました）。

コンテキストや制約が異なれば解決策が違う。だから「べからず集」ではなく「パターン本」なのですね。

アンチパターンに対する解決策

アンチパターンに対して、本来は何がしたかったのかという目的に対する解決策がいくつか紹介されているのがこの本のいいところです。

SQLとツリーにはいろんな議論があって、親idを持つという素朴な方法だけでなく、入れ子集合や閉包テーブルなどのいろいろな技があります。それぞれ得意、不得意があるので、状況に応じて使い分けましょうというのが本書には書いてあります。

何らかの方法を否定するには、背景も含めていろいろ説明しないといけないのですが、指さす先に名前があって、名前の先にはコンテキストやいろいろあって、それが議論をするときの媒介になる。あ、この問題ってやったところだと、これが大事です。

状況に対して、「これどっかで見た」と連想することがパターンにとって大事で、しかもここに書かれているのはデータに関するバグなので影響がでかいんです。この本でアンチパターンに敏感になってほしいなと思います。

で、自分で見つけたパターンがあったら、ブログに書いたりつぶやいたりして、みんなで共有していきましょう。

SQLアンチパターン
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。 リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗(アンチパターン)があります。 本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分かれて、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。